Kymolog

Kymolog™ is medical device integration software. It codes each device reading to FHIR R4, files it in Epic, Oracle Health or five more EHRs, and keeps the same record for research analytics.

Request a demo Visit kymolog.com

Updated

One reading, recorded once, filed twice.
What it does

Medical device integration software for the chart and the study

A continuous glucose monitor reports 132 mg/dL at 08:02. Kymolog writes that value once, as a FHIR R4 Observation with its LOINC code, its UCUM unit, the device that took it and the device’s own clock time. The nurse sees it in the flowsheet. The study dataset gets the same record, and nobody retypes it.

Hospitals use Kymolog to chart bedside device readings. Device makers use it to deliver their readings to hospital EHRs. Researchers and trial sponsors use the same records for analysis, with the provenance attached.

A flowsheet card listing four glucose readings, the newest one highlighted 
{
  "resourceType": "Observation",
  "status": "final",
  "code": { "coding": [{ "system": "http://loinc.org",
            "code": "99504-3" }] },
  "subject": { "reference": "Patient/p-041" },
  "effectiveDateTime": "2026-10-03T08:02:00-04:00",
  "valueQuantity": { "value": 132, "unit": "mg/dL",
                     "system": "http://unitsofmeasure.org" },
  "device": { "reference": "Device/7f3a" }
}
  1. LOINC 99504-3, glucose in interstitial fluid: what was measured, coded so every EHR and every study reads it the same way.
  2. Patient reference, matched by bed and encounter at the FHIR store.
  3. Effective time 08:02, from the device clock and kept apart from the time Kymolog received it.
  4. 132 mg/dL, with its UCUM unit.
  5. Device: the device that sent the reading, for provenance.
Figure 1. One CGM reading as Kymolog files it: a FHIR R4 Observation with its code, unit, patient, device and time. The chart and the study dataset both receive this record.
The platform

A medical device integration platform for Epic, Oracle Health and five more EHRs

An edge agent sits beside the devices and picks up each reading as the device reports it. Kymolog codes the reading to FHIR R4, stamps the device and the time, links the patient, encounter and bed, and delivers it to the EHR the hospital already runs.

Where the hospital’s EHR supports SMART on FHIR, clinicians can open the review queue inside the chart. Epic launch works today, and each deployment chooses whether to use it.

The Kymolog edge agent, a small box with a serial cable running in
  1. 01

    Capture at the edge agent

    An agent beside the devices takes each reading as the device sends it.
  2. 02

    Code to FHIR R4

    A device manifest maps every value to its LOINC code and UCUM unit.
  3. 03

    Stamp the device and the time

    The device and its own clock time travel with the value.
  4. 04

    Link the patient, encounter and bed

    Readings that cannot be matched wait in a review queue.
  5. 05

    Deliver to the EHR

    Over FHIR R4 or HL7 v2, whichever the site runs.
A bedside rack and patient monitor wired to the Kymolog edge agent, which delivers to Epic, Oracle Health, MEDITECH, athenahealth, eClinicalWorks, NextGen and Veradigm
Figure 2. From the bedside rack to the edge agent, then to whichever EHR the hospital runs. Saga also builds the interfaces around an install: see our Epic and Oracle Health integration work.
Devices

Device classes Kymolog supports

Named by class. A new device type is added through a configuration manifest that maps each value to its LOINC code and UCUM unit, with no custom code.

Research

Medical device data analytics for research

The record that reaches the chart also lands in the research store, with its provenance attached: which device took it, by which clock, under which code, and a version for each change. Researchers analyze device data from ICU and ward beds without rebuilding where each value came from.

Sites that want to share data can add the data network, a separate Saga service for consent, de-identification, dataset licensing and royalties. How Kymolog records provenance covers each field.

A study table of glucose readings by subject, time and device
Table 1. The provenance each reading carries into the study dataset.
FieldExampleWhy a study needs it
deviceDevice/7f3a, a CGMSeparates readings by device, for sensitivity analysis and recalls
effective08:02, the device clockThe time the reading was taken
received08:02:41 at the edge agentShows capture lag and clock drift
codeLOINC 99504-3, mg/dLOne meaning across sites and devices
versionv2, corrected at 09:15An audit trail with a version for each change
Deployment

Where the Kymolog install runs

The install runs on premise or in its operator’s own cloud: a hospital’s private cloud, or a device maker’s cloud when the maker runs Kymolog for its hospital customers. The research store runs on premise or in Saga’s cloud.

De-identification runs inside the install’s environment, so a Saga-hosted research store holds de-identified readings only. When a device maker runs the install, identified readings sit in the maker’s cloud under its agreements with each hospital.

The Kymolog FHIR store, a drawer of coded Observation cards
Figure 3. Who holds what. The devices, edge agent, hub, FHIR store and de-identification sit inside the install’s environment; the EHR receives every reading, and a Saga-hosted research store receives de-identified readings only.
Who uses it

Who uses Kymolog

Need the integration work around an install? Interface builds, device validation and EHR flowsheet setup come from Saga’s medical device integration services.

Medical device integration services
FAQ

Kymolog questions

Demo

Request a Kymolog demo

Tell us which devices you use and which EHR you run. We reply within one business day with times to talk. In the demo, a reading from one of your device classes goes into a test chart and a research dataset.

Guides, device pages and the integration details are on kymolog.com.

Required fields