Da Vinci IG implementations have predictable failure modes. The mistakes that broke 2025 production deployments are mostly the same mistakes that surface in 2026 deployments by different vendors. Five mistakes appear consistently and cost implementations time, money, and credibility with customers. For related FHIR infrastructure guides on this site, these are the failure modes worth knowing.
1. Targeting an Outdated IG Version
The most common mistake. The implementation team starts work targeting Da Vinci STU 2.0.0 and never moves to STU 2.0.1 even after the patch ships. Inferno tests configured for the older version pass; Inferno tests configured for the current version fail. CMS conformance assessments may flag the version gap.
The fix is to track IG versions in the implementation roadmap, with platform updates timed to ship within reasonable windows after each new IG release. Vendors with strong IG maintenance commitments handle this automatically; payers building in-house need explicit version-tracking discipline.
2. Ignoring HRex Foundation Profiles
A pattern where the implementation team treats each higher IG (CRD, DTR, PAS, PDex) independently and ignores the HRex foundation that they all build on. The result is internal inconsistency: Patient resources that conform to CRD but not to PDex, Coverage resources that look different across the IGs.
The fix is to read HRex during implementation planning and align the data layer foundations with HRex profiles. The IGs build cleanly on top once the foundation is right.
3. Skipping the Cross-IG Workflow Testing
Inferno tests each IG independently. Many implementations stop there. The workflow that actually matters in production crosses IG boundaries: a CRD card triggers a DTR SMART app that produces a Bundle for PAS submission. The cross-IG integration points have their own failure modes that single-IG testing does not catch.
The fix is to add scenario-based testing that runs the full workflow across IG boundaries. Production-grade implementations validate not just that each IG works in isolation but that the IGs interoperate as a system.
4. Treating CDS Hooks As an Afterthought
A pattern where the CRD implementation is built without deep CDS Hooks engineering. The CDS service returns valid CDS cards, but the cards do not render well across the major EHRs, the action buttons do not trigger expected behavior, and the context handoff to the DTR SMART app drops fields.
The fix is to treat CDS Hooks as a first-class integration layer, not a wrapper. Test against multiple EHR implementations (Epic, Cerner, athenahealth, others). Design cards specifically for the EHR-side rendering quirks. Verify action button behavior end to end.
5. Not Maintaining Conformance Continuously
Implementations that pass Inferno once and stop testing slowly drift out of conformance. Dependency updates, code changes, configuration drift, and IG version updates compound. By the time customers or CMS notice, the gap has grown.
The fix is continuous conformance testing as part of the implementation's normal operations. Run Inferno on a schedule (nightly or per-deployment). Catch regressions immediately. Treat conformance as a continuous engineering concern, not a one-time certification activity.
How These Mistakes Compound In Production
A single mistake might be survivable. A combination is what produces implementations that fail at deployment time or under CMS scrutiny later. An outdated IG version (Mistake 1) plus skipped cross-IG testing (Mistake 3) plus weak CDS Hooks engineering (Mistake 4) produces an implementation that passes some Inferno tests but fails in real EHR integrations.
Vendors with weak track records often combine several of these mistakes. Vendors with strong track records have explicit countermeasures for each.
How to Vet Vendors Against These Failure Modes
A useful vendor-evaluation pattern is to ask explicitly about each mistake. Which IG version do you target now, and what is your version-update commitment. How do you handle HRex foundation alignment. Which scenario-based cross-IG tests do you run. How do you test CDS Hooks behavior across EHRs. How do you maintain conformance continuously.
Vendors with substantive answers to all five are stronger candidates than vendors who hedge or describe one-time certification rather than ongoing engineering.
For the broader IG-version comparison that drives Mistake 1, the STU 2.0.0 vs STU 2.0.1 comparison covers the version detail. For the conformance patterns that prevent Mistake 5, the Top 5 Inferno conformance patterns for Da Vinci implementations covers the testing layer.