HL7v2 or FHIR for Device Data? Both — and here's how we decide
HL7v2 or FHIR for device data? Both — and here's how we decide - SVH Software
Summary
When deciding on data standards for system interoperability, the choice should not be based on whether a standard is old or new. Instead, it must be determined by identifying who the data consumer is and what format they require.
Details
The debate over healthcare interoperability standards (HL7v2 vs. FHIR) is often framed as an 'old versus new' conflict. However, the author argues that the decision must be made on a per-interface basis. According to the text, if the consumer is a clinical system already running on HL7v2 (e.g., lab results into an EHR), sticking with v2 is appropriate. Conversely, for applications like patient-facing apps or dashboards that use REST and JSON, providing FHIR APIs amortizes development costs across multiple future consumers. Device data also shows a split usage pattern. Observations destined for the Electronic Health Record (EHR) often follow the v2 path because that is what the receiving interface accepts. However, observations intended for monitoring dashboards or research are better served as FHIR Observation resources from the start. A key warning is against migrating standards merely for the sake of migration, which can be costly if no new consumer utilizes the data. The recommended architectural approach is to design the 'boundary' rather than the standard itself: centralize device and departmental data where both representations can be produced, allowing each interface to pick its required format based on the specific consumer.
Original content copyright by respective publishers