Skip to content
Med Staff TrackerMed Staff Tracker
For Organizations
SchedulingOnboarding TrackerCredential ManagementIntegrations
For Clinicians
GroupBookCredBook
PricingBlogAboutContactLogin
Get StartedBook a Demo
For Integration Partners

On-call data,
built to be consumed

This page is for the engineering team on the other side of a connection. It covers what we publish, how identifiers and time are handled, and how access is granted. If you were sent here by a shared customer, you are in the right place.

Talk To UsIntegrations Overview
How We Publish

Designed around what actually goes wrong

Schedule integrations tend to fail in the same handful of ways. These are the choices we made in response to each of them.

One flat row per assignment

No nested fetches, no follow up calls to resolve a person or a location. Everything needed to place a clinician on a shift is on the row. This is the single most common reason an integration stalls, so it is the first thing we designed around.

Your identifiers, carried first class

Role, facility, call order and your own system ids are real fields. You should never have to parse them out of a shift name with a regular expression.

Times you can trust

Every time is published with its zone and with a UTC equivalent. Time zone is resolved per location, not per account, so a group covering hospitals in two zones publishes correctly. Daylight saving math is done for you.

Removals are explicit

A cancelled assignment is reported as a removal, not as an absence from the next response. A clinician who comes off a shift should disappear from your platform, and a feed that goes quiet cannot tell you that.

Simple credentials

A key issued by the customer, scoped to the groups and locations they choose. No certification program, no onboarding fee, no annual partner agreement required to get started.

No patient data, ever

Med Staff Tracker is a staffing system. There are no patient records in it, so there are none in anything it publishes. This usually shortens a security review considerably.

The Payload

What arrives on every row

A single assignment carries everything below. Sensitive fields are off by default and enabled per connection by the customer, so treat the contact group as optional.

The assignment

Stable assignment key, publication state, last modified timestamp, and a revision counter that increments on every material change.

When

Service date, local start and end, the IANA time zone, and the same start and end expressed in UTC. Overnight shifts and daylight saving transitions are already resolved.

Who

First and last name, display name, credential, and where permitted work email, mobile, pager and a profile photo. Every one of these is switched on per connection by the customer.

What and where

Shift name, shift type and code, role, call order, location name and code, facility, service line and group.

Your identifiers

Whatever ids you use on your side, carried on the person, the shift, the shift type and the location, so you never have to match on a name.

A full field reference and a sandbox you can query are provided when a connection is set up. If you need to see the exact shape before then, ask us and we will send it.

Getting Started

Three things to get moving

  1. 1

    A shared customer

    Connections are enabled by the customer whose data it is, so the fastest start is a group that runs both systems. If they have already asked you, say so when you contact us.

  2. 2

    An access key

    The customer creates it and chooses which groups and locations it covers. They can rotate or revoke it at any time without involving us.

  3. 3

    Your identifiers

    Send us, or have the customer enter, the ids you use for clinicians, shifts and locations. This is the one genuine setup task, and it is a one time job.

Partner Questions

Technical questions

How do we get started, and how fast can this be live?

Calendar feeds and file exports are self-serve and work today. A direct connection or a scheduled file drop is set up per engagement: we agree the shape with your team, the customer issues credentials scoped to what they want shared, and we work to that customer's date. Tell us who the shared customer is and when they need it working, and we will tell you honestly whether that date is realistic rather than agreeing and slipping.

How often can we poll, and how much can we ask for at once?

Polling intervals in the range most platforms use, from a few minutes upward, are expected and supported. A typical request is a rolling window of the next day or two, which is what most on-call routing needs, and longer windows are available for roster and planning use.

How do we match clinicians to our own records?

Through whatever identifier you already use. The customer records your id against each clinician, shift, shift type and location, and we publish it back to you on every row. We also publish NPI where the customer has permitted it. We deliberately never drop a row because an identifier is missing, because a silently missing clinician is worse than an unmatched one. You decide what to do with an unmatched row.

Can you push to us instead of us pulling from you?

That is on the roadmap alongside the read API, and the shape is a signed message sent to an endpoint you give us when something changes. If your platform prefers to receive rather than fetch, tell us, because it affects the order we build in.

Can you deliver a file instead?

Yes, and for a number of systems that is the expected route. Tell us the layout you need, the delivery location and the cadence, and we can produce it. We treat the file format as configuration rather than code, so an unusual layout is a setup task rather than a development project.

Who do we talk to?

Us directly, through the contact page. We are a small team, which in practice means you reach someone who can answer a technical question rather than a queue. If you are asking on behalf of a shared customer, mention them and it will move faster.