DH EMR Field guides

Cloud sync setup

For the admin who wants several DH EMR Field devices to share one set of records. It sets up a cloud project your organization owns, connects each device, and explains what that does and does not protect. About fifteen minutes, no command line; a single device needs none of this.

What cloud sync gives you

Each device enters visits offline. With cloud sync it also uploads them whenever it has signal and downloads the other devices' visits, so after a sync every device holds every visit, and an admin device's lists, formulary, lab tests, presets and forms reach the whole team.

The project is a Supabase project your organization creates and owns. Damico Health hosts nothing and sees nothing: no central server, no account with us, no subscription.

Field has no user accounts: every device uses the same project address and the same project key. Simple to set up, and also the main limit. Read the honest limit of a shared key before you decide.

Before you start

You need	Where
A Supabase account	supabase.com. The free tier is enough for a small fleet.
`setup.sql` and `verify.sql`	The database setup scripts page of this site. Each has a Copy button; nothing to download or install.
A browser on a computer	The dashboard is easier on a large screen.

Create the project

On supabase.com, choose New project. Any name; pick the region closest to the clinic.
Generate a strong database password and store it in a password manager. It is rarely needed again.
Wait for the project to finish provisioning.

Run the schema

In the left sidebar, open SQL Editor, then New query.
Open the database setup scripts page, press Copy under setup.sql, paste it into the query and click Run. Safe to run twice; re-running is the documented upgrade path.
Recommended: do the same with verify.sql. It changes nothing and ends by rolling itself back.
Every row of its output must say PASS.

Upgrading a project already in use? Run it after clinic hours: it briefly locks the records table, and a device syncing in those seconds shows a sync error, retries, and succeeds. Nothing is lost, but it is alarming to watch mid-clinic.

Get the app credentials

Value	Where in the dashboard	Looks like
Project URL	Project Settings, then Data API. Also in the Connect dialog at the top of the dashboard.	https://yourproject.supabase.co
Publishable key	Project Settings, then API Keys.	`sb_publishable_...`

Every device enters those two values; write them down for whoever sets up devices. That is the whole Field setup: no accounts to create, no sign-in to enable.

The key rule. Devices get the publishable key, or the legacy anon key, and nothing else. Never put the sb_secret_... key or a legacy service_role key on any device, in any chat, or in the app: it bypasses every security rule.

The app refuses keys that look like it, on purpose: "That is a server key (service_role or sb_secret). It bypasses every database security rule and must never go on a field device. Use the Publishable key, or the legacy anon key."

Connect each device

A new device: the setup wizard

On the first screen, tap Connect to our clinic cloud.
On the step headed Connect to your cloud, enter the Project URL and the Project key.
Tap Check and continue.
The app checks that the project's tables exist before letting you go on.
Name the device and choose whether it is an admin device.
Enter the clinic lists and tap Start using the app.

Getting started covers every step and every error message.

A device already in use

Open Settings and find the Cloud sync card.
Tap Connect this device to a cloud.
A form opens with Project address (from your admin) and Project key.
Enter both and tap Verify and connect.
On success: "Connected and registered. Records on this device will upload on the next sync." The card updates at once.
Close and reopen the app so the chip in the top bar updates too.

Visits already on the device upload with that first sync. Connecting registers the device in the project's devices table under the name and role chosen at setup; the security rules accept records only from devices in that table.

If the check fails	Meaning
"That URL or key does not look right. The URL should look like https://yourproject.supabase.co"	A typo.
"Could not reach the project tables:" followed by a reason, or "Connected, but the records table was not found. Run the setup SQL on that project first."	Run the schema was skipped.

Verify with one test visit

On a connected device, enter one test visit and save it.
Tap the chip in the top bar, or Sync now on the Cloud sync card.
"Sync finished. 1 record uploaded. Nothing is waiting."
In the dashboard, open Table Editor, then records.
One row is there.
Delete the test visit in the app, from the patient's chart, not in the dashboard. That marks it deleted on every device; rows are never hard-deleted, by design.
Optional: enter a visit on a second device, sync both, and check that each shows the other's visit on its Visits tab.

Day to day

Sync runs whenever a device is online; anyone can run it by hand with the chip or Sync now. The user guide explains every chip state.

Cloud sync card	Shows
Project	The connected project.
Status	The current sync state.
Waiting to sync	"Nothing pending", or the number of records.

If a sync cannot upload everything the app says so rather than pretending: "NOT backed up." then how many records are still waiting, the reason, and "Take a backup before wiping or handing on this device." Treat that as an instruction.

Organization settings (clinic lists, formulary, lab tests, reference ranges, presets, form templates) are edited on an admin device and reach every device on its next sync. The Form templates card says so: "These belong to your organization; a change reaches everyone on the next sync."

The quick-pick, preset and reference range cards say the same in their own words. On a standard device the organization's lists replace the local ones at the next sync: edit on the admin device only.

The device fleet

All of this is done in the dashboard's SQL Editor. The app cannot revoke, un-revoke or change a device's role, on purpose, so a stolen device cannot either.

List every device

Recognize every row. Revoke strangers.

SELECT id, name, role, created_at, last_sync_at,
       CASE WHEN revoked_at IS NULL THEN 'active' ELSE 'REVOKED' END AS status
FROM devices ORDER BY last_sync_at DESC NULLS LAST;

Revoke a lost or stolen device

Records it already pushed are kept.

UPDATE devices SET revoked_at = now() WHERE id = '<device id>';

Un-revoke a device

UPDATE devices SET revoked_at = NULL WHERE id = '<device id>';

Change a device's role

The cloud role is authoritative: set admin or standard and the device adopts it on its next sync. The app has no control for this.

UPDATE devices SET role = 'admin' WHERE id = '<device id>';

Sanity check the row counts

Run before and after any migration; the numbers must match.

SELECT (SELECT count(*) FROM records) AS records,
       (SELECT count(*) FROM records WHERE deleted IS TRUE) AS deleted_records,
       (SELECT count(*) FROM devices) AS devices,
       (SELECT count(*) FROM config) AS config_rows,
       (SELECT max(saved_at) FROM records) AS newest_record;

Renaming happens in the app, on the This device card with Rename this device, and is always safe: it changes the label only and never re-registers the device. The admin guide covers renaming and replacing devices.

Free-tier pausing

Supabase pauses free-tier projects after about a week without traffic, and one paused long enough (around 90 days) can stop being restorable in place. A team that syncs twice a year and never opens the dashboard can silently lose its cloud copy.

If usage is episodic, upgrade to a paid tier or set a monthly reminder to open the dashboard and click Restore if prompted. Keep device backups regardless: the app's backup file is the true archive; the cloud is a convenience copy for the devices, not the organization's only copy.

Moving to a new project

If you replace the project, for example after a key has leaked, do two things per device.

Tap Change cloud project on the Cloud sync card and point the device at the new project through the same connect form.
Records already on the device upload there on the next sync.
If records exist only in the old project and on no device, export them from it as JSON and bring them in through the Moving from another cloud project card with Import records from a file. The admin guide covers the import.

The card's warning matters: "Export as JSON, not CSV. CSV flattens lab results and medication lists into text and they cannot be read back reliably."

The honest limit of a shared key

Every Field device shares one key. The database cannot tell devices apart, so anyone holding the key can read and write everything in the project. The key is the whole fence.

Limit	What it means
Revoking stops an honest device, not a determined person	Revocation (the device fleet) stops a revoked device from syncing, not someone who copied the key into another tool. After a leak the only real fix is a new project with a new key, and reconnecting every device.
There is no record of who entered what	A visit carries the device that filed it and the provider picked on the form. Nobody signed in, so nothing proves who held the device.
A lost device keeps its data	Revoking does nothing to the records already on it, and they are not encrypted at rest. Treat a lost device as a disclosure.
If you need accounts, you need DH EMR Clinic	Clinic gives every staff member their own sign-in and role. It is a separate product with its own project setup; there is no path from a Field organization into Clinic today.

For a small, trusted team whose devices spend days without signal, the shared key is an honest trade. Give the key only to whoever sets up devices, review the fleet listing now and then, and keep backups.

Back to all guides