FHIRBridge MD
Convert medical device barcodes (UDI/GUDID) into compliant FHIR R4 resources, simulate SMART on FHIR app launches, and inspect EHR telemetry bridges.
HL7 FHIR R4 · FDA GUDID · US Core · SMART on FHIR v2 · 100% free & ungated
Medical Device Barcode ⇄ HL7 FHIR R4 Resource Generator
US Core Profile{
"resourceType": "Device",
"id": "dev-00884838036222-SN-78401",
"meta": {
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-implantable-device"
],
"lastUpdated": "2026-10-26T19:18:38.195Z"
},
"status": "active",
"manufacturer": "Biosensors Interventional Technologies",
"modelNumber": "BM-ALP-3018",
"serialNumber": "SN-78401",
"lotNumber": "LOT-BM-9021",
"expirationDate": "2028-12-31",
"udiCarrier": [
{
"deviceIdentifier": "00884838036222",
"carrierHRF": "(01)00884838036222(17)281231(10)LOT-BM-9021(21)SN-78401",
"entryType": "barcode"
}
],
"deviceName": [
{
"name": "BioMatrix Alpha Coronary Stent System",
"type": "user-friendly-name"
}
],
"type": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "49062001",
"display": "Device (physical object)"
}
],
"text": "Coronary artery stent, drug-eluting"
},
"patient": {
"reference": "Patient/PT-10492",
"display": "Patient Record (PT-10492)"
},
"safety": [
{
"coding": [
{
"system": "https://www.fda.gov/medical-devices/mri-safety",
"display": "MR Conditional"
}
],
"text": "MRI Safety Status: MR Conditional"
}
],
"property": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/device-property-type",
"code": "fda-product-code",
"display": "FDA Classification Product Code"
}
]
},
"valueCode": [
{
"coding": [
{
"system": "https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfPCD/classification.cfm",
"code": "NIQ"
}
]
}
]
}
]
}Medical Device Integration Architecture in Modern Health IT
Connecting medical devices, diagnostics, and software as a medical device (SaMD) to enterprise electronic health record (EHR) platforms requires navigating intersecting standards. Under the 21st Century Cures Act and ONC health IT certification criteria, direct proprietary database connections are prohibited in favor of standardized, auditable APIs: HL7 FHIR R4, SMART on FHIR v2, and the nationwide TEFCA network.
1. Unique Device Identification (UDI) in EHR Workflows
Under FDA 21 CFR 830, medical device manufacturers must assign and mark a Unique Device Identifier on all medical hardware and packaging. The UDI comprises two distinct components:
- Device Identifier (DI): A mandatory, fixed numeric or alphanumeric string identifying the labeler and the specific version or model of the device (represented globally via the GS1 GTIN-14).
- Production Identifier (PI): Variable conditional data elements reflecting manufacturing metadata, including the expiration date, batch or lot number, and unique serial number.
When an implantable device is used during surgery, the perioperative nursing workflow requires scanning this barcode directly into the EHR. Through the US Core Implantable Device profile, this physical data maps directly to a FHIR Device resource linked to the patient record and the corresponding Procedure.focalDevice reference.
2. The SMART on FHIR Authorization Model
SMART on FHIR provides an open, standards-based OAuth2 authentication and authorization specification designed specifically for clinical applications. Whether running within an Epic Hyperspace web frame or as an autonomous backend service, the integration model enforces strict scoping:
- Clinical Scopes: Rather than granting universal database access, apps request granular USCDI scopes such as
patient/Device.readorpatient/Observation.read. - Session Context: During EHR launch, the host EHR injects authorization tokens that bind the application session to the exact patient and encounter currently open on the clinician's workstation, preventing cross-patient chart mismatches.
3. High-Frequency Telemetry and SampledData
Continuous physiological monitoring instruments (such as pulse oximeters, electrocardiographs, and bedside ventilators) produce thousands of data points per minute. Ingesting individual numeric observations for each sample quickly exhausts database indices. FHIR addresses this through the SampledData data structure, condensing full waveform intervals into compact, scaled arrays that preserve high-fidelity clinical morphology without overwhelming network bandwidth.
In-Depth Engineering Reference
For a comprehensive architectural breakdown of SMART on FHIR v2 handshakes, TEFCA and QHIN networks, IEEE 11073 nomenclature, and autonomous AI agents connecting via Model Context Protocol (MCP), read our complete technical guide:
Questions we get
How does FHIRBridge MD translate GS1 UDI barcodes into FHIR R4 Device resources?
The tool parses standard GS1 Application Identifiers from barcode strings: (01) for the 14-digit Global Trade Item Number (GTIN) Device Identifier, (17) for expiration dates, (10) for manufacturing batch/lot codes, and (21) for distinct unit serial numbers. It computes the GS1 Modulo 10 check digit and maps these attributes directly into the udiCarrier and identifier elements of the US Core Implantable Device FHIR profile.
What is the distinction between SMART on FHIR Standalone Launch and EHR Launch?
In a Standalone Launch, the user initiates authorization directly from an external web or mobile application, requesting the launch/patient scope so the EHR presents a patient selection dialog during authentication. In an EHR Launch, a clinician launches the application directly inside the EHR frame (such as Epic Hyperspace activity or Cerner MPages), where the EHR passes an opaque launch context token that resolves directly to the currently active chart.
How are high-frequency biomedical waveforms represented in HL7 FHIR R4?
Rather than storing thousands of individual numeric readings as separate resources, FHIR R4 utilizes the Observation.valueSampledData data type. This structure packages the time interval between successive data points (period in milliseconds), scaling factor, physical unit of measure, and a space-delimited stream of continuous sample integers or decimals, paired with standard LOINC or IEEE 11073 nomenclature.
Why must medical device software interface with US Core rather than base FHIR?
The Office of the National Coordinator for Health IT (ONC) mandates adherence to the US Core Implementation Guide for certified health IT systems under federal interoperability regulations. US Core defines tighter constraints on mandatory elements, such as requiring specific SNOMED CT terminology for device categorization and mandatory udiCarrier fields for implantable hardware.
How do Qualified Health Information Networks (QHINs) and TEFCA relate to local FHIR endpoints?
While local FHIR and SMART apps connect directly to an individual hospital EHR instance, the Trusted Exchange Framework and Common Agreement (TEFCA) enables cross-network patient record discovery across unaffiliated health systems nationwide. TEFCA Facilitated FHIR builds on SMART and FHIR profiles to authorize cross-organization queries without requiring custom bilateral interfaces.
Limited intake