One patient, two settings
Primary care and the hospital, on the same patient
A resident is registered, screened and treated at the rural health unit. When something needs more than primary care can give, they go to a hospital — and come back. eMRCare is built for the first half of that journey, and to hand over cleanly at the point it stops being the right record.
The two records
Different settings need different systems
A rural health unit and a 200-bed hospital do not do the same work, and a record built for one fits the other badly. Primary care turns on empanelment, screening, immunisation, maternal care and the medicines on a formulary. Hospital care turns on admission, wards and beds, theatre scheduling, blood supply and an inpatient bill.
eMRCare covers the first. HealthCore, built by the same team, covers the second — admissions and ward management, operating theatre scheduling, blood bank, inpatient pharmacy and billing, and the hospital's own laboratory and imaging.
Where each one carries the patient
| Setting | Record |
|---|---|
| Barangay health station | eMRCare |
| Rural health unit / primary care facility | eMRCare |
| Konsulta empanelment and capitation | eMRCare |
| Outpatient department, admissions, wards | HealthCore |
| Operating theatre, blood bank | HealthCore |
| Inpatient billing | HealthCore |
Available today
How the hand-off works now
Two mechanisms are in the product today. Both are in use without any bespoke integration work.
Referral records
A clinician refers a patient out of the facility and the referral is recorded against that patient — the reason, the clinical summary, how urgent it is, and where they were sent. Where the receiving facility is another site on the same deployment, the referral appears in that site's queue directly. Where it is an outside hospital, the destination is recorded by name and the referral prints for the patient to carry.
Either way the referral stays on the patient's record, so the next clinician at the health unit can see that it happened, why, and whether it was completed.
A connection the health unit controls
A health unit registers each system it exchanges records with — a hospital, a laboratory, a provincial exchange — and each one gets its own key and its own list of what it may do. Reading a patient's record is one permission; returning a discharge summary, posting a laboratory result, answering a referral and recording an immunisation given elsewhere are others.
Nothing is granted implicitly. A laboratory that posts results cannot read a patient's history unless the health unit ticks that box, and withdrawing one connection does not disturb the others. Permissions can be changed without reissuing the key, and a key can be rotated or revoked the moment it is suspect. Each connection is pointed at a destination so it only receives referrals (and patient access) addressed to that place — not the whole outbound queue.
Every call is recorded against the connection that made it — including the ones that were refused. This is a general capability, not a private arrangement: it is documented, and any system on the other side can use it.
What the other side receives
When a health unit connects a system, it downloads a connection document and sends it to whoever maintains that system: the key, the address, exactly which calls that connection is permitted to make, the shape of each message, and what each response means. Nothing has to be reconstructed from an email thread later, and the health unit keeps a record of what it granted, to whom, and when.
The key appears once, in that document. eMRCare stores only a one-way fingerprint of it, so it cannot be read back afterwards — not by the health unit and not by us. If it is lost, it is rotated rather than recovered.
Being straight about scope
What is built, and what an integration project would add
eMRCare's half of the connection is built. The hospital system still has to use it. eMRCare and HealthCore are separate products with separate databases. eMRCare now publishes the calls a hospital needs — pull the referrals sent to you, look up the patient, send the discharge summary back — and documents them. What it cannot do is write the other system's half: a hospital record system has to be built or configured to make those calls, and that is true of HealthCore as much as of any other product.
So there is no live two-way sync, no shared patient index and no single sign-on across the two. We would rather tell you that here than have you discover it after signing. Joining a specific pair of systems is a defined piece of work, scoped and quoted like any other — it is now a much smaller one than it was, because the interface it plugs into already exists.
Where each piece stands
Agreeing how a patient is identified across both
Still the open question. The health unit knows a resident by its own patient code and their PhilHealth identification number; the hospital knows them by its own. Matching them reliably — and deciding what happens when the match is uncertain — is the first and most important thing to settle, and it is a decision about the two organisations, not something a supplier can decide for them.
Referral reaching the hospital
eMRCare's side is built. A hospital system with the right permission can pull the referrals a health unit has sent it and mark each one acknowledged, declined or completed, so a referred patient is expected before they arrive rather than presenting with a printed form. The health unit sees the status change on the referral its own clinician created.
Discharge summary returned to the health unit
eMRCare's side is built. The half that matters most for continuity, and the half most often missing: what the hospital did, what changed, and what follow-up the health unit now owns. It is sent back against the referral number, so it lands on the record of the clinician who made the referral instead of arriving as a loose document.
Consent and audit across the boundary
Audit and consent are both enforced at the boundary.
Every call a connected system makes is recorded — which connection, what
it reached, whether it succeeded, and what was refused — so a health unit
can show who read what. Patient data leaves only when that patient has
an active Data Sharing consent on file (the same consent the clinic
captures before opening an encounter). Without it the connection is
refused with RFC 7807 problem details (error=consent_required),
and the refusal is written to the audit trail. That is a Data Privacy Act
obligation rather than an optional extra.
Reach is also narrowed by destination: a connection only sees referrals (and the patients on them) addressed to the destination the health unit configured for it. An unset destination receives nothing.
Talk to us about joining the two · How eMRCare handles privacy and consent
One supplier across both tiers
Where an LGU runs health units and a district hospital, both systems come from the same team — one contract, one support line, and a roadmap where the two are planned together rather than negotiated between vendors.