
Surgical pre-op intake sits at the intersection of clinical risk, regulatory consent, and procedural scheduling. The Questionnaire is longer than general intake, the conditional logic branches on prior surgical history and medication lists, and a single missing answer can shift the procedure date. The engines below are the ones US hospital systems pick for surgical pre-op specifically. For more engineering context, see the FHIR engineering reference.
The general selection picture from the complete FHIR intake forms guide applies, weighted toward pre-op clinical depth.
The Engines That Handle Pre-Op Intake
- Smile Digital Health Forms. The commercial SDC engine with vendor-supported pre-op templates. Hospital systems running Smile for clinical FHIR usually extend it to pre-op for the operational continuity.
- Aidbox Forms. Multi-tenant SDC engine with strong server-side conditional resolution; fits ambulatory surgical center networks running pre-op intake across multiple sites.
- LHC-Forms (NLM). The reference open-source SDC renderer. Adopted by hospital systems with strong engineering capacity that want the conformance assurance of the NLM tooling chain.
- Firely SDK Forms. SDK-driven SDC engine used by hospitals building their pre-op UI in-house and wanting a tested engine underneath.
- Phinx Health Questionnaire. A specialty-registry-focused engine with strong support for surgical outcome registries and the pre-op data feeds those registries require.
What Pre-Op Intake Demands Specifically
Three demands separate pre-op from general intake. The first is medication-list reconciliation inside the form. Pre-op intake has to read the patient's current medications, surface them inside the Questionnaire, and capture changes the patient makes. Engines that handle the FHIR MedicationStatement extraction cleanly avoid duplicating the medication list across systems.
The second is depth of clinical conditional logic. Pre-op branches on prior anesthesia events, prior cardiac history, on current pregnancy status, and on dozens of comorbidity flags. Engines that resolve those branches server-side hold up better under audit than engines that resolve them in the patient's browser.
The third is consent and risk-acknowledgement capture. Surgical consent is more stringent than general HIPAA consent; the HIPAA consent walkthrough covers the general case, and surgical pre-op layers procedure-specific consent on top of that baseline.
How Surgical Pre-Op Selection Settles
The choice tracks two axes. The first is whether the surgical service is part of a hospital system or a standalone ambulatory surgical center; hospital-attached pre-op tends to pick the engine already in clinical use, ambulatory-only pre-op tends to pick whatever fits its standalone procurement.
The second is whether outcome registry reporting is a contractual obligation. Practices that report to specialty registries pick Phinx for the registry alignment; practices without that obligation pick the engine that fits their broader FHIR stack. The hospital admission walkthrough covers the adjacent admission flow that surgical pre-op often feeds into, where many of the same engines reappear in a slightly different operational shape.
Sources
- FHIR Questionnaire spec (foundational) - HTML, HL7 build.fhir.org, 2025
- Form Behavior and Calculation - HTML, HL7 SDC IG, 2025
- FHIR Consent resource - HTML, HL7 FHIR R4, 2024











