01 / healthcare
We build against the systems you already run.
Nothing here replaces your charting system. It connects to it, sits in front of it, or removes the work your staff do because it will not talk to something else.
02 / integrations
This is what we integrate with.
This is the surface we build against. Where a vendor publishes a modern API we use it, and where they do not we say so rather than discovering it in week three.
These are charting and practice management systems.
Epic
We work with its FHIR APIs and App Orchard patterns.
Oracle Health Cerner
We work with its FHIR and HL7 v2 interfaces.
athenahealth
We work with the athenaOne APIs.
eClinicalWorks
We work with its interface engine and APIs.
NextGen
We work with its APIs and data export.
Tebra
We work with its APIs and webhooks.
AdvancedMD
We work with its APIs and scheduled export.
DrChrono
We work with its REST APIs.
These are the standards we work in.
HL7 FHIR R4
We use the Patient, Appointment, Coverage and Claim resources.
HL7 v2
We handle ADT, ORM, ORU and SIU messages.
X12 EDI
We handle the 270 and 271, 837 and 835 transactions.
C-CDA
We use it for document exchange.
SMART on FHIR
We use it to launch inside the chart.
DICOM
We work with imaging metadata and worklists.
NCPDP SCRIPT
We use it for electronic prescribing.
Direct messaging
We use it for provider to provider exchange.
These are revenue cycle and payment systems.
Availity
We use it for eligibility and claim status.
Change and Optum
We use them for clearinghouse submission.
Waystar
We use it for claims and remittance.
Stripe
We use it for patient payments and plans.
CAQH
We use it for credentialing data.
Office Ally
We use it for clearinghouse submission.
Payer portals
We script them where no API exists.
Authorize.net and Square
We use them for card present and online payments.
This is the rest of the stack.
Twilio
We use it for reminders, two-way SMS and voice.
SendGrid and Postmark
We use them for transactional email.
HubSpot and Salesforce
We use them for pipeline and referral tracking.
Google Workspace
We use it for identity, Drive and shared inboxes.
Snowflake and BigQuery
We use them for reporting and analytics.
AWS, Azure and Google Cloud
We use them for hosting, with a BAA in place.
Okta and Entra ID
We use them for single sign-on and identity.
Datadog and Sentry
We use them for monitoring and error tracking.
This is a capability list, not a claim of partnership or certification with any vendor named. Where an integration needs a vendor program, an application or a fee, we will tell you that in discovery rather than after you have signed.
03 / data
This is how patient data is handled.
The short version is that PHI stays in your systems. We build against them, we do not copy out of them, and where something genuinely has to store data it is your cloud account, your keys and your audit log.
The controls below are not a compliance program and this page is not legal advice. They are the practical measures that make a system defensible when somebody asks, and they are in place before the first line of production code rather than added afterwards.
- A BAA is signed before access is granted, with subcontractor flow-down.
- Engineers use named accounts and multi-factor authentication, never shared logins.
- Access is least privilege, and it is reviewed when someone joins or leaves.
- Data is encrypted in transit and at rest.
- Audit logging is structured, retained and readable.
- Secrets live in a managed store, never in code or a chat message.
- Test data is synthetic, never a copy of production.
- A written incident procedure is agreed before it is needed.
Some states restrict health data being handled outside the United States, and Medicare Advantage plans impose additional duties on offshore vendors. Tell us your state and your payer mix on the first call and we will tell you what that means for the build. Confirm the current position with your own counsel: this is a moving area and we are engineers, not lawyers.
04 / ai
We follow three rules for AI in a clinical business.
A person approves anything that reaches a record.
Models draft, extract, summarize and route. A human approves before anything reaches a patient record, a claim or a payer. The approval is part of the workflow, not a policy in a document nobody opens.
Every generation is logged.
The log records the input, the output, the model, the version, the timestamp and the person who approved it. When an auditor asks how a value got into a record, the answer is a query rather than a recollection.
Every AI step is measured against a real error rate.
Before an AI step goes live we run it against a labelled sample and tell you how often it is wrong and in which direction. If the number is not good enough for the task, we build the deterministic version instead.
05 / questions
These are the questions we get asked first.
Do you sign a BAA?
Yes, before any access is granted rather than after the first sprint. It covers permitted uses, safeguards, incident reporting, what happens to data when the engagement ends, and any subcontractor we use. If we bring in a specialist, the agreement flows down to them.
Where does patient data live?
It lives in your systems. We build against your charting system, your clearinghouse and your cloud accounts, and we do not copy PHI into infrastructure we own. Where a system genuinely has to hold data, it is your cloud account, your encryption keys and your audit log.
Engineers work under named accounts with multi-factor authentication and least-privilege access, and access is reviewed when someone joins or leaves the engagement.
Have you integrated with our charting system?
The list on this page is the surface we work against. Where a vendor publishes a modern API we use it. Where they do not, the honest answer is that the integration runs on HL7 v2 messages, a scheduled export or a supported interface engine, and it takes longer to build and more care to keep running.
Ask us on the first call and we will tell you which of those three your system is, before you have committed to anything.
How do you handle AI and patient data?
There are three rules, and we do not bend them. Nothing goes to a model provider without a signed agreement covering it. Nothing a model produces reaches a patient record or a payer without a person approving it. Every generation is logged with its input, its output and the person who approved it, so an audit can be answered with evidence rather than assurances.
We will also tell you when a task does not need AI. A rules engine that is right every time beats a model that is right most of the time, and it is cheaper to run.
Do you do AI scribes?
We integrate them, we do not sell our own. That means helping you choose between the ambient vendors, wiring the output into your chart so the note lands in the right place, making sure the clinician signs it rather than a system filing it silently, and measuring the error rate against a labelled sample before it goes anywhere near a live clinic.
There are two honest caveats. Ambient tools are good at a straightforward single-clinician visit and weaker on multi-speaker visits, complex specialties and anything where the note is only half the job. If what you need is a person who also handles orders, referrals and the inbox in the same hour, that is a human scribe, which is a sister company rather than a piece of software. We will point you there instead of selling you a tool that does not fit.
Will you build us a patient portal?
We almost certainly will not, and the reason is security rather than capability. A bespoke portal means a second copy of patient data, in a second system, with a second attack surface, a second patching schedule and a second thing to explain at audit. Most of the time it exists to save patients a login.
Your EMR already holds that data and already carries the burden of protecting it. We would rather build inside its portal, extend what it can do, and put the work where the risk already lives. If your EMR genuinely cannot do what you need, we will tell you that and scope it properly, with the risk written down rather than glossed over.
Can you take over something another firm built?
We often can, and it is a large part of what we do. It starts with a fixed-cost review: we read the code, the infrastructure and the deployment process, and give you a written assessment of what is sound, what is fragile and what would have to be replaced.
Sometimes that assessment says rebuild. We will show you the reasoning rather than asserting it, because a firm that recommends a rebuild on every inherited system is selling, not assessing.
Do you work with practices outside the United States?
The healthcare work is built around United States practices, payers and standards, so that is where we are useful. The Medical Operations works from Dubai and the United States, and every company in the division serves United States practices.
06 / next
Bring us the integration nobody wants.
Think of the eligibility check done by hand, the fax that becomes a referral, and the report assembled every Monday morning. Those are the jobs worth automating first, and they are the ones we would rather scope.
Start a project07 / contact
Get in touch.
Tell us the system, the standard it speaks and the workflow that is costing you hours.
Dubai
Meydan Free Zone
Dubai, United Arab Emirates
United States
Spring City, PA 19475
United States