Consulting
We work with US labs, providers, and health-tech vendors on the integration work that has to be right the first time — ingesting an HL7 v2 feed, fielding X12 eligibility, posting an 835 remittance, reading a C-CDA on referral, decoding a DICOM study, handling a Surescripts ePrescribing round-trip, or wiring a FHIR client to a payer API. Spec-grounded, PHI-safe, and honest about what is and is not solved.
The work
Concrete transactions across the standards the open-source suite covers, shown as the spec actually on the wire — not a capability deck. Every engagement starts from what a real message looks like.
HL7 v2 · MLLP
Receive ADT, ORU, or ORM messages over MLLP from an EHR, lab, or upstream interface engine — parsed leniently, never silently dropped, acknowledged correctly, and routed downstream.
MSH|^~\&|EPIC|MERCYGEN|CLOVERLEAF|MERCYGEN|20240117093000||ADT^A01|MSG00001|P|2.5.1
EVN|A01|20240117093000
PID|1||MRN0012345^^^MERCYGEN^MR||DOE^JANE^Q||19800101|FX12 270/271 · X12 835
Respond to 270 eligibility requests in time and post 835 remittances to AR — claim-status, segment-level error reporting, and payer-quirk handling included.
ISA*00* *00* *ZZ*AETNA *ZZ*MERCYGEN *240117*0930*^*00501*000000001*0*P*:~
ST*835*0001~
BPR*C*1250.00*C*ACH*CCP*01*011000015*DA*0000123456*1512345678~C-CDA R2.1
Extract the clinically relevant facts from a referral or transition-of-care document — problems, medications, allergies, recent vitals — into a typed model your downstream code can trust.
<section>
<templateId root="2.16.840.1.113883.10.20.22.2.5.1"/>
<code code="11450-4" codeSystem="2.16.840.1.113883.6.1"
displayName="Problem List"/>
</section>DICOM Part 10
Parse the metadata, identify the SOP class, route the study to the right destination, and de-identify before anything leaves the boundary — without pulling in a 50 MB SDK.
(0008,0016) UI SOPClassUID 1.2.840.10008.5.1.4.1.1.2 # CT Image Storage
(0008,0060) CS Modality CT
(0010,0020) LO PatientID ANON-0012345NCPDP SCRIPT
NewRx and RxChange round-trips with a pharmacy or PBM — the XML envelope, the structured SIG, the prescriber/pharmacy NCPDP IDs, and the SCRIPT error semantics.
<Message version="2017071" xmlns="http://www.ncpdp.org/schema/SCRIPT">
<Body><NewRx><MedicationPrescribed>
<DrugDescription>Amoxicillin 500 MG Oral Capsule</DrugDescription>
</MedicationPrescribed></NewRx></Body>
</Message>FHIR R4 · CMS-0057-F
Implement the Prior-Authorization, Patient Access, or Provider Access API surfaces against a payer FHIR endpoint — US Core conformance, OperationOutcome error handling, and the right resource shapes.
{
"resourceType": "Coverage",
"status": "active",
"subscriberId": "SUB0012345",
"payor": [{ "reference": "Organization/aetna" }]
}Who we work with
Reference, hospital, and specialty labs that need LIS interop, results delivery to ordering providers, and clean ordering and billing pathways.
Hospitals, clinics, and ambulatory practices that need EHR integrations to ship correctly — claims, eligibility, referrals, results, and prescribing.
Companies whose product exchanges clinical data with EHRs, payers, registries, or labs — and need their interop work to be spec-clean and PHI-safe by default.
Engagement model
A bounded discovery call, a written scope, an implementation that ships as a pull request you own, and an optional retainer for the parts that compound.
Step 1
A 30-minute working call. What you have, what has to come out the other side, the spec actually on the wire, and whether cosyte is the right fit. Free.
Step 2
A written scope — deliverables, acceptance criteria, calendar bounds, fixed price — that we both sign before any code is cut. BAA executed before any PHI touches our environment.
Step 3
Code, fixtures, and tests written against the actual spec. PHI-safe by construction. Delivered as a reviewable pull request into your repository, not a black box hand-off.
Step 4
Hand-off documentation plus, optionally, a retainer for the parts that compound — runtime support, a new transaction set, the next payer your team takes on.
Regulatory context
Three rule and program names a US healthcare-integration buyer's compliance team will already recognise — flagged as context, not as a reason to panic.
Compliance dates begin January 1, 2027
The CMS Interoperability and Prior Authorization final rule (finalized January 2024) requires impacted payers — Medicare Advantage, Medicaid managed care, CHIP managed care, and QHP issuers on federally facilitated exchanges — to stand up FHIR-based Prior-Authorization, Patient Access, Provider Access, and Payer-to-Payer APIs.
Why it matters — If your product exchanges prior-auth or member data with a US payer in 2027, a conformant FHIR API surface stops being optional. The engineering work is now, not in Q4 2026.
Operational since 2023
The Trusted Exchange Framework and Common Agreement is the national-scale clinical-data exchange built on top of designated Qualified Health Information Networks (QHINs). Multiple QHINs are carrying production traffic, with FHIR-based exchange rolling in alongside the existing IHE document-based flows.
Why it matters — TEFCA participation — directly as a QHIN participant or indirectly through a QHIN sub-participant — is increasingly the default way to reach a broad provider network without standing up dozens of point-to-point integrations.
NPRM issued 2024; finalization in process
ONC's HTI-2 proposed rule continues to extend EHR certification — public-health reporting modules, USCDI version progression, additional FHIR API capabilities, and decision-support requirements.
Why it matters — Each certified EHR your product or organisation integrates with continues to surface more standardised FHIR endpoints. The integrations you build against those endpoints today get more reusable, not less, as certification widens.
FAQ
Tell us what's on the wire and what has to come out the other side. We read the spec, write the code, and stay honest about what's solved.