Short answer: through the REST API Juno inherits from OSCAR, authorized once by your clinic with OAuth 1.0a. Your Juno host switches REST on, a REST client is registered for ZeroMiss, and a clinic administrator approves access in a one-time sign-in. ZeroMiss then reads appointment times to find openings and writes appointments only after a patient is matched and confirms. It never receives your Juno password and never touches charts.
The setup checklist
- Ask your Juno host to enable REST for your instance. On OSCAR-based systems it's a server setting, off unless someone turns it on.
- Register a REST client for ZeroMiss in Juno's administration. This gives ZeroMiss its own client identity that you can revoke at any time.
- Create a dedicated Juno user for ZeroMiss with only the access scheduling needs. Bookings made by the assistant are then easy to spot and audit.
- Approve access once. A clinic administrator signs in to Juno and approves the ZeroMiss client. The resulting token goes into a secret for your clinic only; we never ask you to email keys.
- Tell us each practitioner's bookable hours and services. The REST API doesn't expose schedule templates, so openings are your stated hours minus what's already booked in Juno.
- Test in test mode. Your clinic stays in test until you're satisfied, with bookings made by your own testers.
What ZeroMiss reads and writes
| Juno data | Used? | Why |
|---|---|---|
| Appointments per practitioner per day | Read | To compute real openings |
| Patient demographics search | Read | To match a patient by name and date of birth |
| New patient record | Write | Only when no match exists and the patient confirms |
| Appointment | Write / cancel | Book, move (book new, then cancel old) and cancel, each after Confirm |
| Charts, notes, labs, documents, billing | Never | Not needed for reception |
The safety rules are in code, not in the prompt
- Offered times only. The assistant can't book a time it didn't offer from a fresh availability check.
- Identity never goes through the AI. Name and date of birth are typed into secure fields, sealed with your clinic's own encryption key, and matched on the server.
- No write without a Confirm. The server issues the Confirm card; the AI can't press it.
- Same answer for strangers. A wrong date of birth gets the same reply as someone who isn't a patient, so the chat can't be used to probe who's on your roster.
- A separate gateway holds the keys. Only ZeroMiss's EMR gateway can read your Juno credentials, and it returns internal ids, not names.
A known quirk worth planning for: on OSCAR 19-based systems the API's appointment-update call is unreliable, which is why ZeroMiss moves an appointment by booking the new time first and cancelling the old one second, undoing the new booking if the cancel fails.
Frequently Asked Questions
Where are the Juno access keys stored?
In a secret dedicated to that one clinic, readable only by ZeroMiss's EMR gateway, a private service that no other part of the system or any other clinic can use. The rest of ZeroMiss gets patients back as internal ids, not names.
Do Juno REST tokens expire?
On some OSCAR-based systems the token lifetime is short by default (an hour). We confirm it with your Juno host during setup; if a token expires, the assistant takes a callback request and we reconnect, rather than failing silently.
Can we revoke ZeroMiss's access?
Yes, at any time, by removing the REST client or the dedicated user in Juno. When a clinic leaves ZeroMiss we also delete its keys and destroy its encryption key.
Does this work with plain OSCAR too?
Yes. ZeroMiss also connects to OSCAR installations; the setup depends on your version and host, so we confirm the details on a call.
Bottom Line
Juno's open, OSCAR-derived API is what makes direct booking possible, and it's also why the setup is mostly on your side: your host enables REST, you register a client and approve it once. After that, ZeroMiss books into Juno under strict, code-enforced rules and never sees more of your EMR than reception needs.