Health Data Interoperability Planning Template

HL7v2 is a message-based standard from the 1990s that is still the most widely deployed interface in US healthcare. It uses pipe-delimited segments (MSH, PID, OBR, OBX) and is typically used for ADT (admit-discharge-transfer), lab results, and order messages. C-CDA is an XML-based document standard used for clinical document exchange (discharge summaries, care plans). FHIR is the modern RESTful API standard that represents clinical data as granular resources (Patient, Observation, MedicationRequest). New integrations should default to FHIR where the partner supports it; expect to encounter HL7v2 interfaces at smaller hospitals and legacy systems.

For a single use case (e.g., submit vitals to Epic via FHIR), expect 3-6 months from kickoff to production. This includes partner onboarding (4-6 weeks), development (4-8 weeks), sandbox testing (2-4 weeks), security review (2-4 weeks), and production go-live. Multi-use-case integrations or integrations with smaller EHR vendors that have less mature APIs can take 6-12 months.

ONC Health IT Certification is required if your product is an EHR or a module that contributes to EHR certification criteria. Most health tech products that connect to EHRs (like RPM platforms, DTx apps, or patient engagement tools) do not need ONC certification themselves. However, you must comply with the 21st Century Cures Act information blocking rules, which require that you do not unreasonably restrict data sharing when a patient or provider requests it.

Document the unmapped elements explicitly and define a handling strategy: (a) map to the closest parent concept and flag for human review, (b) send the original text as a free-text element alongside the coded value, or (c) reject the data and alert the source system to provide a mappable code. Never silently drop unmapped data. The receiving system needs to know what it is not getting.

SMART on FHIR is an authorization framework (built on OAuth 2.0) that enables third-party apps to securely connect to EHR systems. You need it when your app launches within the EHR context (e.g., a provider clicks a link in Epic to open your app with patient context) or when your backend service uses delegated authorization to access FHIR APIs. Most major EHR vendors (Epic, Cerner, Allscripts) require SMART on FHIR for third-party app integration. ---