The most impressive trait about the Jelvix team is that you can't give them a task or idea too large. No matter how grand a vision you may have, they'll always have a solution or means to accomplish it.
Thank you, Jelvix, making our vision into a reality. You executed, delivered and were responsive through the whole project. The finished product has an awesome look, feel and user experience that will change the way physical therapists and patients interact between visits.
Our application was finished and able to generate revenue within one year as the Jelvix team adhered to the required timeline efficiently and professionally. They were communicative, responsive, and always available to take on feedback and make tweaks or changes as required.
Jelvix delivered digital products that are fit for purpose and, in the case of the mobile apps, award-winning. Led by an engaged project manager, communication with the development team is smooth and purposeful. They contributed conceptually to the solutions and were excited to problem-solve.
Our goal is to build software solutions that truly matter, making the world a better place for everyone while helping entrepreneurs succeed in their journey.
For 16 years, Jelvix has been a strategic tech partner for global leaders and innovators. We leverage high-end design, rigorous QA, and expert consultancy to engineer scalable solutions that turn complex business challenges into market-leading products.
Epic runs 42% of acute-care EHRs in the US, yet no two provider sites work the same way.In this project, enterprise software was developed to connect the client-designed application to Epic and Oracle Health using an FHIR/HL7 framework.
The client is a digital health scale-up focused on digital diabetes management and chronic care across the US and UK, with a B2B SaaS platform for remote patient monitoring of diabetes patients. Each new provider site required a separate integration built from scratch, running 16–20 weeks.The client needed healthcare software development experts who could build an integration architecture their engineering team wouldn’t have to rebuild for every new site.
The platform needed to integrate with Epic and Oracle Health across multiple provider sites without rebuilding from scratch each time. This created a three-layer challenge.Operational PainDesigned for remote patient monitoring of diabetes patients, the solution lacked reconciliation for FHIR R4 and HL7 v2 messages. TIR calculation did not consider warm-up, gaps, or units, nor did it check for drift until the payer’s audit. It would take 16–20 weeks of customization for each new site.Scalability RoadblockBuilding custom point-to-point connections for every new healthcare provider site prevented the B2B SaaS platform from scaling rapidly.
Business RiskValue-based care contract requirements necessitated being audit-ready with TIR, TBR, and TAR lineage data, but because of the absence of FHIR Provenance for all Observation aggregates, this was not possible. Doctors required TIR reports as well as daily glucose charts that were directly written into the patient record, rather than requiring a separate dashboard to view.Technical BottleneckThere was no standard approach to managing differences in the ability to write EHRs across locations. Without quota management, API rate limiting was arbitrary under high demand. In the past, a payer had experienced issues with their bulk FHIR export request timing out.
Instead of building a one-off connection for each provider site, our engineers designed a reusable HL7 FHIR integration framework to accelerate diabetes management app development.Component 1: Site Capability MatrixEvery new service site begins with a capability audit. This matrix gives information about the write-back (full, partial, and read-only), API quota, and Bulk FHIR. Runtime toggles transform the matrix to automate behavior. In case a full write-back isn’t possible, the data is wrapped up as FHIR resources and placed in a deferred write-back queue until the gate opens for writing through FHIR or HL7.Component 2: EHR Broker (FHIR R4/R5 + HL7 v2)The broker issues idempotency keys upon ingestion, ensuring that readings from each channel generate only one canonical record. Based on HL7 FHIR integration tools healthcare teams can rely on, it supports Epic and Oracle Health by means of FHIR R4/R5 standards, SMART on FHIR, and HL7 v2 ORU^R01 standards as a failover mechanism.Component 3: Outcomes Engine (TIR/TBR/TAR)Warm-up exclusion, time-of-day exclusion, and unit canonicalization guarantee that all Time in Range diabetes calculations follow clinical standards. All consolidated FHIR observations include complete Provenance, including their effectivePeriod and calculation methods.Component 4: Bulk and Cohort ReportingNightly cohort jobs, backfills, and payer dashboard feeds are provided by SMART Backend Services. The Bulk FHIR $export process is available to handle large populations via pagination and retry functionality, with no timeouts. The cohort dashboard provides Time in Range diabetes statistics per patient, which can be shown to payers immediately.
Unified FHIR R4/R5 & HL7 v2 Broker
TIR Calculations with Full FHIR Provenance
In Glucose Calculations & Unit Conversions
The platform runs on a six-domain architecture built on HL7 FHIR integration tools healthcare teams can deploy for predictable EHR go-lives.EHR Integration Domain: SMART on FHIR adapters for Epic and Oracle Health, employing FHIR R4/R5 Observation resources for point-of-care glucose data and FHIR R4/R5 DiagnosticReport or DocumentReference data elements for consolidated cohort data. ORU^R01 is the backup data element. Adaptive write-back functionality can degrade into a read-only function based on the Site Capability Matrix.Data Quality Domain: Idempotency layer with a de-duplication engine for resolving multiple feeds, both FHIR and HL7 v2, to one canonical record; unit canonicalization in mg/dL and mmol/L and timezone canonicalization.Outcomes Domain: A custom Python engine that computes the TIR, TBR, and TAR as per the clinical formula, where the warm-ups are excluded, and there is a clear gap policy along with full FHIR Provenance in every Observation aggregate. The AI development approach allows anomalies to be detected above the calculation.Cohort and Payer Domain: SMART on FHIR integration for cohort jobs running every night, Bulk FHIR $export with pagination/retries support, PostgreSQL database backend for payer-level dashboards that provide patient-level insights into payer metrics.Observability Domain: CloudWatch and Datadog monitor quotas and throttling per EHR, with per-site negative write testing and alerting before issues reach clinical workflows.Compliance Domain: HIPAA and GDPR controls across the full pipeline, with a FHIR Provenance chain, consent ledger, audit logs, and DPIA templates ready for payer audit.
The following knowledge base was required in six team members for the project implementation:Solution Architect: FHIR/HL7 architecture design and site capability matrix;Integration Engineers (2): EHR connector development and HL7 v2 to FHIR reconciliation;Backend Engineer: TIR/TBR/TAR outcomes engine, idempotency layer, and retry logic;QA Automation Engineer: TIR math validation across warm-up intervals, unit conversions, and timezone drift;DevOps Engineer: Kubernetes and AWS setup, CI/CD pipeline, and quota management;Security & Compliance Lead: HIPAA/GDPR controls, audit logging, and DPIA templates
Jelvix delivered the project through a phased integration approach.1. Discovery and Capability Audit The audit documented the quota levels for reading, writing, and API usage for all sites where EHRs were operational, taking into account the combined FHIR and HL7 v2 feed behavior. From the experience gained in chronic care management, each site went into Phase 2 with a capability matrix.2. Broker and OutcomesAdapters for EHR brokers for Epic and Oracle were developed first, after which the idempotency and deduplication layer was created. The outcomes engine was tested using synthetic data involving DST changes, sensors backfill, and changing units mid-session. Provenance was added to all transformations from day one.3. Site Enablement Each site completed SMART app registration, clinical context user acceptance testing, and quota tuning for each EHR instance. When necessary, HL7v2 routing reconciliation has also been done. The average period for site enablement is 6 weeks.
SMART on FHIR integration was used for EHR integration that supports a variety of sources and clinical outcomes, and large-scale cohorts for payers:Healthcare Standards: FHIR R4/R5, SMART on FHIR (user-context + Backend Services), HL7 v2 ORU^R01, Bulk FHIR $exportEHR Connectivity: Epic API, Oracle Health / Cerner API, SMART app registration, site capability matrixIntegration Layer: Python, FastAPI, Redis, custom de-duplication engineOutcomes Engine: Python, custom TIR/TBR/TAR calculator, FHIR Observation + Provenance resourcesCohort & Reporting: PostgreSQL, Bulk FHIR $export with pagination and retries, payer dashboard layerCloud & DevOps: AWS (EKS, RDS, S3), Kubernetes, CI/CD pipeline, GitHub ActionsObservability: CloudWatch / Datadog, custom quota alerting, per-site negative write testsSecurity & Compliance: HIPAA/GDPR controls, FHIR Provenance chain, audit logging, consent ledger, DPIA templates
The digital diabetes management app team got a repeatable, documented path to every new EHR site.
Every new provider site follows the same audit, configuration, and enablement sequence, cutting go-live from 16–20 to 6 weeks.
The TIR, TBR, and TAR are all clinically compliant across all connected facilities. Clinicians can view outcomes within the EHR interface without having to leave the system.
Cohort reports follow payer guidelines from the get-go. Complete Provenance for all observations gives full traceability right away without any additional work.
A new payer or CGM device connects through the existing framework, and payer analytics scales with the network.
The EHR integration framework delivered faster go-lives and payer-grade cohort reporting.
Every TIR, TBR, and TAR Observation carries full data lineage with zero unit-mix defects in production.
The idempotency layer resolved mixed FHIR and HL7 v2 feeds into a single canonical record per clinical event.
SMART Backend Services and Bulk FHIR $export produced dashboards ready to present to payers without further processing.
Sites run at full write-back capability or fall back gracefully to read-only with captured intent of the clinicians.
Connectors can be reused, and a capability matrix allowed us to eliminate custom development per site by documenting a configuration process.
No payer audits follow-up visits at any site. The Provenance chain was complete with first submission.
We will contact you within 24 hours to discuss your project in more detail.
Please refresh the page and try again
When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.