Cardiology services running on Epic face a recurring choice when they extend their intake stack: build new capture in Epic SmartForms and stay inside the EHR, or capture via FHIR Questionnaire and route the responses into Epic via the FHIR API. Both paths are valid in 2026; the right one depends on what the cardiology service wants to do with the captured data beyond the clinical chart. For more on FHIR product comparisons, the broader walkthroughs cover related decisions.
What Each Path Actually Gives You
Epic SmartForms are the EHR-native option. They render inside Hyperspace, feed Epic-native flowsheets and SmartData elements, and require no external infrastructure beyond what the EHR team already runs. The trade-off is that the captured data lives in Epic's internal model; getting it back out for research, registry submission, or a third-party analytics platform requires a Clarity report or a Caboodle pipeline, which is a separate effort.
FHIR Questionnaire is the standards-native option. The same Questionnaire definition renders in a third-party SDC renderer or in Epic's own FHIR Questionnaire support, and the resulting QuestionnaireResponse is a portable resource that any FHIR-aware downstream system can read. The trade-off is that the cardiology service is now running a form engine outside Epic, with its own deployment, support, and security review.
Where the Two Diverge for Cardiology Specifically
Cardiology workflows expose three places where the two paths diverge meaningfully. Registry alignment is the first. The IMPACT registry and the NCDR submissions expect FHIR-shaped Observations and Procedures. SmartForms can produce these via mapping logic, but the FHIR Questionnaire path produces them natively. Calculated-expression complexity is the second; Epic SmartForms handles its own calculation language well, while FHIR Questionnaire uses FHIRPath, which is portable across vendors but newer to Epic-trained staff. Multi-site reuse is the third; a cardiology group with practices on different EHRs gets a single Questionnaire definition that works everywhere, while SmartForms only render inside Epic.
For a single-site cardiology service that lives entirely inside Epic, SmartForms wins on day one. For a multi-site cardiology group, a research-active cardiology practice, or any cardiology service that submits to multiple registries, FHIR Questionnaire pays off within the first year. The cardiology cornerstone walks through the full selection framework, and the pediatric cardiology intake walkthrough shows where the choice lands for the pediatric sub-specialty.
How Most Teams Should Decide in 2026
The practical decision rule is: build inside SmartForms if the form's only consumer is the Epic chart and the cardiology service has no plans to share the data outside Epic. Build on FHIR Questionnaire if the form's data has to go anywhere else, even one place. The crossover point keeps moving toward FHIR as more registries, payers, and quality programs adopt FHIR-native ingestion in 2026 and beyond.
Neither path is wrong; they optimize for different futures. The wrong move is to commit to one without thinking through where the cardiology service's data has to flow over the next three years.
The right answer depends less on the abstract architecture and more on where the cardiology service's data has to flow over the next three years. Once that destination map is drawn, the SmartForms-vs-FHIR-Questionnaire question usually answers itself, and the team can commit to one or the other without revisiting it every quarter.
Most multi-site cardiology groups in 2026 end up running both: SmartForms for the Epic-native workflow that drives the clinical chart, and FHIR Questionnaire for the registry-bound and research-bound capture. That parallel approach handles the operational realities better than a forced single-platform commitment, as long as the team is explicit about which data flows where.
Sources
- the standards-side comparison anchor - HL7 FHIR R5 Questionnaire resource
- the FHIR-native path for structured data capture - HL7 SDC IG
- the EHR-side base profile for cardiology demographics - HL7 US Core Patient profile