Interpreting sync status
What read_status and write_status mean, what the four combinations tell you, and how to fix a sync that is down.
Two questions tell you whether a practice's data is current: when did NexHealth last read from the health record system, and when did the sync last check in for writes? GET /sync_status answers both for every sync on a practice. The Developer Portal shows the same thing.
The four fields
read_status_at. The last time NexHealth read data from the system. Everything NexHealth returns for that practice is as fresh as this timestamp.read_status.greenwhen the last read is recent,redwhen it is not. The line is 150 minutes by default and can be set per sync.write_status_at. The last time the sync checked in for writes waiting to go into the system. The sync checks in whether or not anything is waiting.write_status.greenwhen the sync checked in recently,redwhen it has not. The line is 25 minutes by default.
The two statuses are worked out from the two timestamps. Nobody sets them by hand.
What the combinations mean
read_status | write_status | What is happening |
|---|---|---|
| green | green | Normal. Reads and writes are flowing. |
| red | green | The sync is running and will take writes, but reads have stalled. What you read may be stale. |
| green | red | Reads are arriving, but the sync is not picking up writes. Anything you write waits. |
| red | red | The sync is off. The server is off, or nobody is logged in to a cloud system. |
A gap between the two timestamps is normal. During the day it moves between 0 and about 20 minutes.
When the status changes
- A status turns red on its own when its timestamp ages past the line.
- The
sync_status_read_changeandsync_status_write_changewebhooks fire both ways:sync_status_read_change.redwhen reads go down andsync_status_read_change.greenwhen they come back, and the same for writes. Subscribe to both, and still checkread_status_atbefore you trust a read. - Outside business hours, and above all on weekends and holidays, expect both timestamps to be hours or days old. That is not a fault. See the next section.
Downtime is normal
Server-based systems. The office manages the hardware that runs the database. Syncing happens only when the server is on. Expect downtime when the office is closed. Depending on how the office runs its server, that can be every night or every weekend.
Cloud-based systems. The office uses the health record system through a web browser. The sync relies on user activity in the Chrome extension. The last read and write timestamps update only while office staff are logged in to both the Chrome extension and the health record system. They also have to be working in the schedule. Expect downtime overnight, on weekends and on holidays. It can also happen during lunch breaks or long staff absences.
For the best performance, install the Chrome extension on as many workstations as possible.
Monitoring
To monitor sync status, poll GET /sync_status. You can also check status in the Developer Portal.
The most common causes of unexpected downtime depend on the type of system.
Server-based systems. The NexHealth services may no longer be on the server where you installed them. This often happens when antivirus software quarantines or deletes the files. The office may also have replaced its physical server. In both cases, you need to reinstall the services on the server. To prevent this, we strongly recommend that you allow NexHealth services in antivirus and firewall settings before the install.
Cloud-based systems. The office may not have the Chrome extension on enough workstations. Install it on every workstation where staff change the schedule. Each sync has its own token, which you can find in the portal.
How to fix a sync that is down
Server-based sync. If a sync has been down for a long time and needs a reinstall, use the self-installer at nexhealth.com/download. A reinstall needs a new product key. For now, only the NexHealth support team can generate product keys. Developers cannot create them in the Developer Portal.
To request a new product key, email [email protected] with the name of the institution. Product keys are unique to each institution. Start a separate email thread for each request and check that you use the right key for each install.
Cloud-based sync. If a cloud-based sync has been down for some time, the office likely does not have the Chrome extension on enough workstations. Ask the office to install the Chrome extension and sign in to it. That restores the sync.
Updated 18 days ago