Essay
Surface works with your clinical system, API or no API
Every healthcare provider in Chile believes their clinical system disqualifies them. The record is half filled in, the service catalogue exists in three versions, the schedule lives in another module, and nobody has an API to offer. That belief is the number one reason an institution never calls.
Surface works between the order a doctor writes and the appointment that actually happens. To hold that ground we need to read four things from your system. The rest is our work.
What does Surface need from your system, exactly?
The honest list fits on one line. If your system can produce these four fields, even out of a spreadsheet somebody exports by hand on a Friday afternoon, Surface can work.
- What was ordered. The text exactly as it was written into the medical record, unnormalised. Normalising it is our job.
- For whom. A stable patient identifier. A national ID works. An internal ID works too.
- When. The date of the consultation or of the order. That is how we compute urgency and queue position.
- How to reach them. A mobile number. An email address on top of that is better.
What we do not need, worth saying out loud because it is exactly what stalls the conversation:
- A clean service catalogue. Yours has duplicates and different names per site. Everyone's does.
- Normalised codes. If national billing codes, ICD-10 or your own internal matrix come through, we use them. If they do not, we work from the text.
- A complete record. We work with what is there and flag what is missing.
- Write access to your schedule. For the first weeks booking can happen by hand in your own interface, under your own user, the way it happens today.
Do I need an API?
No. There are two paths and both are finished product.
The real integration. A connection to your clinical system, a scheduled extract, continuous reads. It is where almost every provider ends up and it is where Surface performs best: full coverage, no blind windows, nobody exporting anything.
The CSV you control. You decide the columns, which sites are included, the date window and the cadence. If one Tuesday you want to send half the base, you send half. If you want to stop sending for a week, you stop without calling anyone.
The second path usually reaches the first result sooner, for a boring reason: it does not queue. An integration goes through the IT roadmap, the deployment window, the security review and sometimes the system vendor, who charges for the connector. An exported report goes through none of that.
More than one Chilean buyer has asked to start exactly this way: integrate nothing, download from their own system, until the numbers justify opening the window for IT.
| Real integration | CSV you control | |
|---|---|---|
| Time to first result | Week 2 if the IT window is already open. Their roadmap sets the calendar. | Week 2. You set the calendar. |
| What IT has to do | Credentials, an endpoint or a read view, and a security review of the connection. | One report exported from the system they already use, dropped in a folder. |
| Provider control | Fixed at connection time. Changing the scope takes another round with IT. | Total and reversible. You change columns, sites or cadence whenever you want. |
| Coverage | Everything the system exposes, continuously refreshed. | Whatever fits in the extract. It widens one column at a time. |
| Writing to the schedule | Possible where the system allows it. | By hand in your own interface, under your own user. |
| When it fits | When IT already has the window open or the volume justifies the project. | When you want the number before asking IT for anything. |
The two paths converge. The usual sequence is to start from the extract and move to the connection once the result is on the table and IT has something to justify the project with.
What if the orders arrive as free text?
They arrive as free text. Almost always.
A doctor writes “abd US + RUS”, or “brain MRI w/ con”, or “gastro” when they mean an upper endoscopy. The scheduling system stores a referral code that says “MRI” and loses the rest: laterality, days of preparation, and whether contrast is required.
That detail decides the appointment. An MRI with contrast medium needs a different slot, different preparation and sometimes a different site than the same MRI without contrast. If whoever books it does not know which one it is, the patient travels, the exam cannot be done, and they leave.
The field that settles the question is usually printed on the paper the patient carried out of the consultation, and that paper never entered the system.
- gastro, EGD, upper scope: upper endoscopy.
- abd US, abdominal echo, belly ultrasound: abdominal ultrasound.
- CAT, scanner, tomography: CT scan.
Reading that prose is the work. Surface takes the text as it is, resolves it against your institution's own service catalogue, infers laterality, contrast and preparation days when the text mentions them, and escalates the case to your team when it does not.
When it stays ambiguous, the agent asks: it requests that the patient read out the order in their hand. The logic behind that decision is published. The alias map, exam by exam, lives in the exam guides.
Does it work with TrakCare, Rayen, Masterkey or Epic?
Yes. What determines the work is the shape of the extract your system can produce, far more than the brand that system carries.
We have worked against systems of each shape: high-complexity hospital records with their own scheduling module, primary-care clinical registries, occupational-health records extracted with a script and a dictionary of codes, and international suites with published interoperability standards.
Where the standard exists, we use it. HL7 FHIR defines six exchange mechanisms (RESTful API, messaging, documents, services, database and subscriptions) and any of the six produces what we need.
Where it does not, the CSV is the standard. Rayen Salud, for instance, states it is present in over 76% of Chile's primary care facilities. If your centre is one of them, the conversation starts from which report you already know how to export.
There is one page per system, with what we know about each: InterSystems TrakCare, Rayen Salud, Masterkey, Epic, and the full index.
What you will not read on any of those pages: that we are a certified partner of that vendor, or that we have a connector of theirs running in production. When we do, we will say so with a name and a date.
- Do you need write access to my medical record?
- Not to start. We read the extract and book in your own interface for as long as write access is not enabled.
- Does an Excel file work instead of a CSV?
- Yes. Any stable tabular format works: CSV, XLSX, JSON or a database view. What matters is that the columns do not get renamed every week.
- How often does the file have to be sent?
- Daily is the norm, because an order goes cold fast. Weekly works and it shows in the result.
- Do you need identifiable patient data?
- We need an identifier and a phone number. Anonymisation happens inside your institution and the agents never see the patient's identity.
What does your IT team actually have to do?
Less than it fears. On the CSV path, this is the complete list:
- Decide who exports and from where. It is usually somebody already running that report for something else.
- Agree the format once. We send the column spec, you say which ones you can deliver. Half an hour.
- Drop the file somewhere. An SFTP, a bucket, a shared folder. Whichever one you already have.
- Schedule the send at whatever hour suits them.
- Pass their own security review and sign the data processing agreement.
None of those steps touches your clinical system, deploys software inside your network, or opens a project in the IT portfolio. Step 5 is the slowest one, and it depends on your institution.
One more thing we do not ask of your team: operating Surface. Through the ramp-up we do the schedulers' job ourselves, with the founders in the operator's chair. This is how we work.
How long does it take?
Three weeks, counted honestly. Setup on day 1. Production in one week. Results from there on.
The first week goes into three things: closing the extract format, registering the WhatsApp number under your brand, and loading your scheduling rules. By the second week the agent is already writing to patients.
The day-by-day calendar is published, and the denominator the result gets measured against is agreed before anything starts: how we measure.
Where does the data live and who owns it?
Yours. The extract is yours, the conversations are yours, and the number the patient sees carries your brand. We operate as data processor: your institution defines the purposes, we execute on its instructions, under Chile's Ley 19.628.
Your protocols and your rules run on top of Surface and are followed with 99.9999% accuracy. If your policy says nobody gets written to after 8pm, nobody gets written to after 8pm. Your brand, your data covers the legal and ownership side.
What if my system really is further behind than most?
Almost everyone believes theirs is. Chilean clinical systems are an archipelago: one record per level of complexity, one schedule per site, one service catalogue per unit, and scheduling rules that live in the personal spreadsheet of the scheduler who has been there eight years.
That mess gives us work, and the work is ours. The one thing that would block a project is having no way to know what was ordered and for whom, and we have yet to find that case: if your institution bills the service, somewhere it was written down that it was ordered.