Device data for your hospital customers and your post-market evidence

Hospitals that buy your device expect its readings in their EHR. Kymolog's edge agent gets them there at every site, as coded FHIR R4 data. Each reading also keeps your device's UDI and the time it was taken, so your post-market team can trace every value back to a unit in the field.

Get your device into hospital EHRs Plan a one-site post-market data pilot

UDI · FHIR R4 · LOINC · UCUM

Fig. 1. A device's trace drawn as two lines, one to the hospital's EHR and one to your post-market evidence file.

Where real-world evidence for medical devices comes from

Your device takes readings every day in routine care, and hospitals chart them. Those charted values are real-world data, but they usually reach the EHR without their provenance: which unit took the value, when, and during which patient encounter. Without it, a post-market team can't rely on them next to complaint files, registries and published studies.

FDA's final guidance on real-world evidence for medical devices (December 2025) explains how the agency judges whether real-world data is of sufficient quality to generate evidence. Kymolog™ keeps the provenance with each reading from the moment of capture.

Get your device's data into hospital EHRs

Getting device data to the EHR is a different job at every customer: each hospital runs its own EHR under its own interface rules. Kymolog gives your device one path into the seven EHRs on our list.

Coding at the edge agent

At the bedside, an edge agent takes the values your device already outputs and writes each one in the format EHRs accept: a Fast Healthcare Interoperability Resources (FHIR) R4 Observation. The Observation names the measurement with a LOINC code and its unit with UCUM. Every reading records your device's identity, including its serial number and UDI. Because the agent codes each reading at capture, a measurement carries the same code at every site.

Delivery to each hospital's EHR

Each reading gets its patient and encounter from the bed the device is assigned to at that hospital. Kymolog then files it in the hospital's own EHR: Epic, Oracle Health (Cerner), MEDITECH, athenahealth, eClinicalWorks, NextGen or Veradigm, as FHIR R4 or through an HL7 v2 interface. See the EHRs and delivery paths.

Hosting at the hospital or in your cloud

Each hospital can run Kymolog on its own hardware, or in a cloud account it controls. You can also run it in your own cloud on behalf of those hospitals. Each hospital's patient data then lives in your cloud, under the agreement you sign with that hospital. We only ever receive de-identified readings, for a hosted research store or the data network, because the install de-identifies them before they leave.

Medical device integration with the EMR, without a build per EHR

A direct integration is one build per EHR vendor, followed by mapping, testing and sign-off at every hospital that runs it. An EHR upgrade can reopen the work, and the cost grows with every customer site.

With Kymolog, your device is onboarded once, as configuration: a manifest that lists its measurements, their LOINC codes and their units. Every site then receives the same coded readings, whichever EHR it runs.

Get your device into hospital EHRs

Real-world evidence and post-market data

Your post-market team needs the readings the hospital charts, plus proof of where each one came from. Kymolog stores the two together, in the same record.

What each reading carries

Every reading points to the unit that took it: its serial number, UDI, model and device type. It carries a timestamp precise to the millisecond and, inside the install, the patient and encounter it was matched to. It records whether a clinician approved, rejected or reassigned it, by whom and when, and when it reached the EHR. Device-use periods show which patient each unit was assigned to, and for how long.

Kymolog also keeps device health readings, such as battery, signal strength and uptime, so field-performance evidence sits next to the clinical values.

The UDI and device-provenance chainFrom the label to the reading. The device label carries its UDI in GS1 form: (01)00614141004126, the device identifier (DI), then the production identifier (PI): (17)281231, expiry 31 December 2028; (10)L2604, the lot; and (21)SN00412, the serial. The DI is the key to the device’s record in FDA’s GUDID. The FHIR R4 Device Device/7f3a carries the UDI for this one device: udiCarrier.deviceIdentifier 00614141004126, issuer GS1 (http://hl7.org/fhir/NamingSystem/gs1-di), serialNumber SN00412, lotNumber L2604, expirationDate 2028-12-31 and manufacturer, your company. A DeviceUseStatement records that Device/7f3a was on Patient/p-041 from 2026-10-01T09:14:00-04:00. Every Observation names the device: device Device/7f3a, subject Patient/p-041, effectiveDateTime 2026-10-03T08:02:00-04:00, code LOINC 99504-3, and the value 132 mg/dL, in red.UDI ON THE LABEL(01)00614141004126(17)281231(10)L2604(21)SN00412DIPIFDA GUDIDdevice record,keyed by the DIFHIR R4 DEVICEDevice/7f3audiCarrier.deviceIdentifier00614141004126udiCarrier.issuerhttp://hl7.org/fhir/NamingSystem/gs1-diserialNumberSN00412lotNumberL2604expirationDate2028-12-31manufactureryour companyFHIR R4 OBSERVATIONdeviceDevice/7f3asubjectPatient/p-041effectiveDateTime2026-10-03T08:02:00-04:00codeLOINC 99504-3valueQuantity132 mg/dLFHIR R4 DEVICEUSESTATEMENTwho wore it, from whendeviceDevice/7f3asubjectPatient/p-041timingPeriod.start2026-10-01T09:14:00-04:00
The UDI and device-provenance chainFrom the label to the reading. The device label carries its UDI in GS1 form: (01)00614141004126, the device identifier (DI), then the production identifier (PI): (17)281231, expiry 31 December 2028; (10)L2604, the lot; and (21)SN00412, the serial. The DI is the key to the device’s record in FDA’s GUDID. The FHIR R4 Device Device/7f3a carries the UDI for this one device: udiCarrier.deviceIdentifier 00614141004126, issuer GS1 (http://hl7.org/fhir/NamingSystem/gs1-di), serialNumber SN00412, lotNumber L2604, expirationDate 2028-12-31 and manufacturer, your company. A DeviceUseStatement records that Device/7f3a was on Patient/p-041 from 2026-10-01T09:14:00-04:00. Every Observation names the device: device Device/7f3a, subject Patient/p-041, effectiveDateTime 2026-10-03T08:02:00-04:00, code LOINC 99504-3, and the value 132 mg/dL, in red.UDI ON THE LABEL(01)00614141004126(17)281231(10)L2604(21)SN00412DIPIFDA GUDIDdevice record,keyed bythe DIFHIR R4 DEVICEDevice/7f3audiCarrier.deviceIdentifier00614141004126udiCarrier.issuerhttp://hl7.org/fhir/NamingSystem/gs1-diserialNumberSN00412lotNumberL2604expirationDate2028-12-31manufactureryour companyDEVICEUSESTATEMENTwho wore itdeviceDevice/7f3asubjectPatient/p-041timingPeriod.start2026-10-01T09:14:00-04:00FHIR R4 OBSERVATIONone readingdeviceDevice/7f3asubjectPatient/p-041effectiveDateTime2026-10-03T08:02:00-04:00codeLOINC 99504-3valueQuantity132 mg/dL
Figure 2 as a table
FieldValue
label: (01) device identifier, the DI00614141004126
label: (17) expiration date281231
label: (10) lotL2604
label: (21) serialSN00412
FDA GUDIDthe device record, keyed by the DI
Device: udiCarrier.deviceIdentifier00614141004126
Device: udiCarrier.issuerGS1 (gs1-di)
Device: serialNumber, lotNumberSN00412, L2604
Device: expirationDate2028-12-31
Device: manufactureryour company
DeviceUseStatement: device, subjectDevice/7f3a, Patient/p-041
DeviceUseStatement: timingPeriod.start2026-10-01T09:14:00-04:00
Observation: device, subjectDevice/7f3a, Patient/p-041
Observation: effectiveDateTime2026-10-03T08:02:00-04:00
Observation: code, valueQuantityLOINC 99504-3, 132 mg/dL
Fig. 2. The provenance chain for one reading. The Observation names its Device, the Device carries the UDI from the label, and the UDI’s device identifier is the key to the device’s GUDID record. The UDI shown is an example.

Post-market surveillance and PMCF

In the US, section 522 of the FD&C Act lets FDA order post-market surveillance of certain class II and class III devices, under 21 CFR Part 822. In the EU, the Medical Device Regulation expects post-market clinical follow-up (PMCF) as part of each device's clinical evaluation. Both call for data from real use.

A site running Kymolog produces that data during routine charting: coded readings from your device in routine care, each traceable to a unit, a time and an encounter. Each hospital decides which of those readings you may use, and in what form, even when the install runs in your cloud. Medical device clinical trials at the same site can use those records too.

PMCF data from a site installThree places, left to right. In the site install, which runs at the hospital or in your own cloud, your device takes a reading; Kymolog codes it as FHIR R4 with LOINC, UCUM and the device’s UDI, and files it in the EHR; a de-identify step keeps allowlisted fields, replaces the patient with a token and shifts the dates. Consented, de-identified records go to the data network, an optional add-on: 1, consent terms agreed with the site; 2, pooled across sites and licensed; 3, royalties paid back to the site. At your company, the PMCF plan (EU MDR Annex XIV Part B, section 6) says what data to collect. The licensed dataset holds the reading: token t-8c41, time 08:02 with the date shifted, LOINC 99504-3, value 132 mg/dL in red, DI 00614141004126 and lot L2604. Its analysis goes into the PMCF evaluation report (section 7), which feeds the clinical evaluation (section 8) and the PSUR (Article 86).THE SITE INSTALLyour deviceKymologat the hospital or inyour cloud: FHIR R4,LOINC, UCUM, the UDIde-identifyallowlist, token,shifted datesthe EHRthe chartData networkoptional1consent terms agreedwith the site2pooled across sites andlicensed3royalties paid to thesiteYOUR COMPANYPMCF planwhat to collect, and how;MDR Annex XIV Part B, section 6LICENSED DATASETone rowtokent-8c41time08:02, date shiftedloinc99504-3value132 mg/dLDI00614141004126lotL2604PMCF evaluation reportsection 7; into the clinicalevaluation (section 8) and thePSUR (Article 86)
PMCF data from a site installThree places, left to right. In the site install, which runs at the hospital or in your own cloud, your device takes a reading; Kymolog codes it as FHIR R4 with LOINC, UCUM and the device’s UDI, and files it in the EHR; a de-identify step keeps allowlisted fields, replaces the patient with a token and shifts the dates. Consented, de-identified records go to the data network, an optional add-on: 1, consent terms agreed with the site; 2, pooled across sites and licensed; 3, royalties paid back to the site. At your company, the PMCF plan (EU MDR Annex XIV Part B, section 6) says what data to collect. The licensed dataset holds the reading: token t-8c41, time 08:02 with the date shifted, LOINC 99504-3, value 132 mg/dL in red, DI 00614141004126 and lot L2604. Its analysis goes into the PMCF evaluation report (section 7), which feeds the clinical evaluation (section 8) and the PSUR (Article 86).THE SITE INSTALLyour deviceKymologat the hospital or inyour cloud: FHIR R4,LOINC, UCUM, the UDIde-identifyallowlist, token, shifted datesthe EHRthe chartData networkoptional1consent terms agreed with the site2pooled across sites and licensed3royalties paid to the siteYOUR COMPANYPMCF planwhat to collect, and how;MDR Annex XIV Part B, section 6LICENSED DATASETone rowtokent-8c41time08:02, date shiftedloinc99504-3value132 mg/dLDI00614141004126lotL2604PMCF evaluation reportsection 7; into the clinical evaluation (section8) and the PSUR (Article 86)
Figure 3 as a table
StepWhereWhat happens
1the site installthe device takes a reading; Kymolog, at the hospital or in your cloud, codes it (FHIR R4, LOINC, UCUM, UDI) and files it in the EHR
2the site installde-identified before it leaves: allowlisted fields, a patient token, dates shifted
3data networkconsent terms agreed with the site
4data networkpooled across sites and licensed to you; royalties paid to the site
5your companythe PMCF plan (MDR Annex XIV Part B, section 6) says what data to collect
6your companylicensed dataset row: t-8c41, 08:02 (date shifted), LOINC 99504-3, 132 mg/dL, DI 00614141004126, lot L2604
7your companyPMCF evaluation report (section 7), into the clinical evaluation (section 8) and the PSUR (Article 86)
Fig. 3. Post-market clinical follow-up data from one site install, at the hospital or in your own cloud. Readings are de-identified before they leave the install; through the data network, consented readings of your device reach your PMCF evaluation, and the site is paid royalties.

Our guides cover the obligations in detail: medical device post-market surveillance and PMCF for medical devices.

The data network option

Some device makers need data from more sites than they work with directly. We run the data network as a separate add-on service. Hospitals that choose to take part contribute consented, de-identified device data and earn royalties on it. Device makers and others can license datasets built from that data. How the data network works.

Plan a one-site post-market data pilot

Start with EHR delivery or post-market data

You can start with either one: your device in one customer's EHR, or a post-market data pilot at one site. Both run on the same install, so adding the second needs no new integration. We reply within one business day with times to talk.

Get your device into hospital EHRs Plan a one-site post-market data pilot