Integration services
HL7, FHIR, X12, NCPDP, ASTM and DICOM. The libraries stay free and MIT-licensed, so you can read every line the work is built on. What you pay for is the integration itself: the interface, the mappings, the tests and, if you want it, running it.
Who it is for
Your product has to exchange data with a customer’s EHR, a payer or a lab. You can install our libraries and build it yourself. When you would rather keep your team on the product, we build the interface in your repository, in TypeScript, as pull requests with tests.
You run the interfaces between an EHR, labs, imaging and everything downstream. We build new HL7 v2 feeds over MLLP, C-CDA document exchange and FHIR endpoints, alongside the engine you already run or as code your developers own.
Claims, remittance, eligibility and enrollment in X12 005010, and pharmacy claims and ePrescribing in NCPDP. We build the parsing, the validation and the reconciliation around them, with every amount kept in exact decimal arithmetic.
Packages
Each package is a fixed scope at a fixed price, agreed in writing before any work begins. Tell us which one fits and what is on the wire, and we send you the price for your scope.
We run a sample of your traffic through our parsers and report every deviation from the standard, what your current integration does with each one, and what to fix first. Real traffic under a signed BAA, or a synthetic sample if you prefer.
You get: A written report, the parser warnings grouped by cause, and a fix list in priority order.
One HL7 v2 interface over MLLP, inbound or outbound: the connection, acknowledgements, parsing, the mapping to your target system or format, and error handling.
You get: Code in your repository, a test suite on synthetic messages, and a runbook.
One FHIR R4 connection to an EHR or a payer API: the client, the resource mappings you need, validation against the profiles you use, and handling of OperationOutcome errors.
You get: Code in your repository, a test suite on synthetic resources, and a runbook.
One X12 005010 flow, such as posting 835 remittances, answering 270 eligibility requests or sending 837 claims: parsing and building, validation, and the reconciliation logic around it.
You get: Code in your repository, a test suite on synthetic interchanges, and a runbook.
One NCPDP flow: Telecom claims (billing, reversal and rebill) or SCRIPT ePrescribing messages (new prescriptions, renewals and changes), with reject handling.
You get: Code in your repository, a test suite on synthetic transactions, and a runbook.
One analyzer connected over ASTM framing and records, or one DICOM flow: reading the metadata you need, routing studies, and applying a de-identification policy to their metadata before they leave your boundary.
You get: Code in your repository, a test suite on synthetic traffic, and a runbook.
After we build an integration, we can run it: monitoring, library and dependency upgrades, and the changes that follow when a trading partner or a vendor changes what they send.
You get: A fixed monthly scope, written down, and a record of every change we make.
How it runs
Step 1
The contact form is enough: the standard, the systems on each side, and what has to come out the other end.
Step 2
Deliverables, acceptance criteria and a fixed price, signed before any work starts. If protected health information is in scope, we sign a Business Associate Agreement first.
Step 3
Pull requests you can review, on our open-source libraries, with tests on synthetic data.
Step 4
You own the code either way. If you want it run, that is the Run it package.
The full engagement model and the questions buyers ask before signing are on How we work.
Open source
Every integration we build runs on the same MIT-licensed @cosyte/* packages anyone can install. When a fix is general, it goes back into the library for everyone. Your integration code stays yours.
Protected health information
We sign Business Associate Agreements.
Tell us what is on the wire and what has to come out the other side.