Clinical Update — June 2026: This guide has been revised to reflect Greenway Health's Q1 2026 GAPI endpoint versioning changes, the finalized ONC HTI-2 rule's expanded USCDI v4 data class requirements for problem list interoperability, and updated CMS interoperability enforcement timelines. Section-level write-back behavior, addendum failover logic, and FHIR Condition posting sequences have been validated against Intergy build 12.40. If you previously implemented based on the January 2025 edition, review Sections 2, 5, and 6 for breaking changes.

Greenway Health Interoperability Guide: GAPI, FHIR, and Real-Time Clinical Write-Back for Intergy

TL;DR: Greenway Health's Intergy EHR requires a hybrid interoperability approach that most implementation guides ignore. CMS standards cover FHIR R4 and USCDI at the payer-exchange level but never address how to write discrete clinical data back into a proprietary EHR during an active encounter. This guide details how Scribing.io uses the GAPI Note Object alongside FHIR Condition resources to achieve real-time, section-level write-back (CC, HPI, A/P) without Citrix UI automation—ensuring clean billing, audit-ready documentation, and zero disruption to clinical workflows. If you are a Director of Clinical Informatics evaluating ambient AI for Intergy, this is the only technical reference you need.

Table of Contents

• Why CMS Interoperability Standards Alone Cannot Solve Greenway Intergy Write-Back

• The Hybrid GAPI+FHIR Pattern for Intergy

• Clinical Logic: Real-Time Encounter Resolution for a Diabetic Foot Ulcer on Intergy over Citrix

• Technical Reference: ICD-10 Documentation Standards for E11.621 and L97.409

• GAPI Note Object Architecture: Section Keys, Concurrency, and Failover

• FHIR Condition Posting and Problem List Synchronization

• Citrix-Safe Performance: Sub-100 ms Streaming Without UI Automation

• E/M Auditability: Diarization-Driven Medical Decision-Making Separation

Why CMS Interoperability Standards Alone Cannot Solve Greenway Intergy Write-Back

The CMS interoperability framework—anchored by USCDI, HL7 FHIR R4.0.1, US Core profiles, and the SMART App Launch IG—serves a specific purpose: enabling payer-to-provider and patient-facing data exchange at the API layer. It defines how health plans expose claims data, how prior authorization requests transmit via Da Vinci PAS, and how consumers access their records through CARIN Blue Button profiles. The CMS Interoperability and Patient Access final rule and the subsequent ONC HTI-1 and HTI-2 rules enforce these standards at the regulatory level.

What these standards do not address—and what the CMS standards index explicitly omits—is the real-time, intra-encounter write-back problem that every ambient AI scribe must solve for EHRs like Greenway Intergy. Scribing.io exists because this gap is not theoretical; it produces claim denials, audit failures, and documentation that looks complete but is structurally hollow. This is the gap that matters to a Director of Clinical Informatics evaluating documentation tools for a Greenway-based practice.

The CMS resource correctly identifies HL7 FHIR R4.0.1 and the US Core IG as foundational. For Greenway-specific implementations, these remain essential for patient-facing data access under the 21st Century Cures Act. But for the ambient AI use case—where an AI scribe must write structured data into a clinician's note in real time—FHIR alone is insufficient. You need the GAPI Note Object.

This distinction is why organizations evaluating ambient AI integrations across multiple EHR platforms, including Epic Integration and athenahealth API configurations, find that each EHR demands a platform-specific write-back strategy layered on top of standards-based interoperability.

The Hybrid GAPI+FHIR Pattern for Intergy

Real-time write-back to Greenway Intergy requires utilizing the GAPI Note Object to ensure discrete data fields (CC, HPI, A/P) are populated without disrupting Citrix-based remote desktop performance. Scribing.io extends this with a hybrid GAPI+FHIR pattern built on five architectural pillars:

1. Pre-Commit Validation

Before any data touches the note, Scribing.io validates three critical identifiers against the GAPI session context:

• encounterId — Confirms the encounter is open, active, and matches the ambient session's time window

• serviceLocationId — Ensures data routes to the correct practice location (critical for multi-site Greenway deployments where a single Intergy instance serves multiple offices)

• ownerProviderId — Verifies the authenticated provider matches the note owner, preventing cross-provider data contamination during shared-workstation scenarios common in Citrix environments

This validation step catches mismatches that produce silent data misrouting—a failure mode that surface-level integrations miss entirely because they assume the session context is always correct.

2. Optimistic Concurrency with Version/Lock Awareness

The GAPI Note Object exposes a version state and lock indicator. Scribing.io reads this state before every write operation:

• If the note is unlocked and current, the section-level update proceeds with the expected version token.

• If the note's version has advanced (indicating a staff edit occurred between reads), Scribing.io performs a merge-and-rebase rather than an overwrite, preserving any concurrent human edits.

• If a version conflict is unresolvable (e.g., the same section was modified by both the MA and the AI within the same second), the system surfaces a clinician-facing prompt rather than silently dropping data.

3. Automatic Addendum Failover on Signature Lock

When Intergy marks a note as signed, the GAPI rejects direct section writes. Competing tools either fail silently or queue data that never lands. Scribing.io detects the signed state and automatically creates an addendum note linked to the original encounter, ensuring:

• Late-dictated content (common in complex visits) still reaches the chart

• The addendum carries full provenance metadata: timestamp, author, AI-assist flag per AMA augmented intelligence guidelines

• The original signed note remains untouched for compliance under HIPAA amendment rules (45 CFR §164.526)

4. FHIR Condition Resource Posting for Problem List Integrity

This is the critical layer most ambient AI vendors miss. While the GAPI handles note text, diagnoses must also propagate to the problem list for billing and longitudinal care. Scribing.io simultaneously posts a FHIR Condition resource that:

• Links each Assessment item to the encounter's problem list

• Maps natural language diagnoses to both ICD-10-CM and SNOMED CT codes

• Sets clinicalStatus, verificationStatus, and onset fields per US Core Condition profile requirements

• Ensures the problem list update is visible to downstream billing workflows before the claim is generated

5. Idempotent Retry Queue for GAPI Rate Limits

Greenway's API enforces rate limits via HTTP 429 responses. Scribing.io queues writes with idempotency keys derived from encounterId + sectionKey + contentHash, ensuring:

• Retries never produce duplicate note content

• The queue drains in FIFO order with exponential backoff

• Sub-100 ms section updates continue via the local stream buffer while retries resolve in the background

This architecture is what separates a purpose-built Greenway integration from a generic ambient AI tool that treats every EHR as a text box. For a comparison of how this pattern adapts across EHR platforms, see our Epic Integration guide, which details the equivalent FHIR-native approach for Epic's open APIs.

Clinical Logic: Real-Time Encounter Resolution for a Diabetic Foot Ulcer on Intergy over Citrix

Scenario: A family physician on Greenway Intergy—hosted over Citrix—sees a 63-year-old patient with established type 2 diabetes and a new foot ulcer. The medical assistant (MA) documents the chief complaint and vitals at intake. The physician examines the patient and dictates the assessment and plan.

What a Competing Tool Does Wrong

1. The A/P is free-texted into a single undifferentiated text block. The diagnoses "type 2 diabetes mellitus with foot ulcer" and "non-pressure chronic ulcer of unspecified heel and midfoot" appear as prose but are never encoded as discrete ICD-10 codes.

2. E11.621 and L97.409 never reach the encounter's problem list or the billing module. They exist only in the note body.

3. After the physician signs the note, a staff member edits the HPI to add a missing medication detail. Because the competing tool has no concurrency awareness, its queued write fires after the staff edit and overwrites the corrected HPI with the original AI-generated version.

4. The claim denies. Without coded diagnoses on the problem list, the payer's adjudication system cannot validate medical necessity per CMS ICD-10 coding requirements. The practice must rework the claim manually—a process that costs an average of $25–$118 per reworked claim according to the AMA's administrative burden data.

What Scribing.io Does Differently: Step-by-Step

Phase 1 — MA Intake (t = 0:00 to t = 4:30)

1. Diarization identifies MA voice. Scribing.io's speaker diarization engine tags all utterances from the medical assistant, distinguishing them from the patient and any accompanying family members.

2. Chief Complaint routes to cc section key. The MA says, "What brings you in today?" The patient responds, "I've got this sore on my foot that won't heal." Scribing.io extracts the CC—"non-healing foot ulcer"—and writes it to the GAPI Note Object's cc section key with author: MA provenance.

3. HPI begins populating. As the patient describes the two-week duration, worsening redness, and associated drainage, this content routes to the hpi section key. Each sentence streams in under 100 ms latency from transcription to GAPI write.

4. Vitals remain native. The MA enters blood pressure, pulse, weight, and glucose directly into Intergy's structured vitals module. Scribing.io does not interfere with this workflow—ambient AI should never override structured data entry points that already work.

Phase 2 — Physician Examination and Dictation (t = 4:30 to t = 14:00)

1. Diarization switches to provider voice. The physician enters the room and begins the encounter. Scribing.io's diarization engine detects the new speaker and routes subsequent clinical content to provider-attributed sections.

2. HPI augmentation with MDM context. The physician asks clarifying questions: "When did you first notice the ulcer? Have you been checking your blood sugars?" These responses augment the HPI, appended below the MA-captured content with clear authorship delineation. The GAPI write uses the current version token, ensuring no overwrite of the MA's prior entries.

3. Physical exam findings populate the pe section key. "Right heel, 2 cm ulcer with serous drainage, no erythema extending beyond the wound margin, pedal pulses palpable bilaterally." This lands discretely in the physical exam section.

4. Assessment dictation triggers ICD-10 mapping. The physician states: "Assessment: Type 2 diabetes with foot ulcer. Non-pressure chronic ulcer, right heel." Scribing.io's clinical NLP engine maps these to:

   • E11.621 — Type 2 diabetes mellitus with foot ulcer

   • L97.409 — Non-pressure chronic ulcer of unspecified heel and midfoot, unspecified severity

   These codes are written to the assessment section key as structured diagnosis entries—not free text.

5. Plan dictation populates plan section key. "Start daily wound care with silver sulfadiazine dressing, off-load with a diabetic boot, recheck in one week, and refer to podiatry if no improvement." Each plan element maps to the corresponding assessment item, maintaining the A/P linkage that E/M auditors require per AMA E/M guidelines.

Phase 3 — Concurrent FHIR Condition Posting (t = 14:00 to t = 14:02)

1. Simultaneous FHIR POST. While the GAPI writes finalize the note sections, Scribing.io issues parallel FHIR Condition resource POSTs:

   • Condition #1: code: E11.621, clinicalStatus: active, verificationStatus: confirmed, subject: Patient/[id], encounter: Encounter/[id]

   • Condition #2: code: L97.409, clinicalStatus: active, verificationStatus: confirmed, linked to Condition #1 via the Condition.extension:dueTo to represent the causal relationship between diabetes and the ulcer

2. Problem list updates before billing review. Both conditions appear on the patient's Intergy problem list. When the billing staff opens the encounter for claim generation, the ICD-10 codes are already populated—no manual lookup, no transcription from note text to claim form.

Phase 4 — Signature Lock and Addendum Failover (t = 14:05 to t = 14:20)

1. Physician signs the note at t = 14:05. Intergy's signature lock engages. The note's version state changes to signed.

2. A staff member edits the HPI at t = 14:10 (via Intergy's amendment pathway) to add a missed medication: "Patient reports taking metformin 1000 mg twice daily." This edit creates a new version of the HPI section.

3. A competing tool's queued write fires at t = 14:12. It attempts to write its original HPI content, overwriting the staff amendment. The staff correction is lost.

4. Scribing.io detects the signature lock at t = 14:05. Any pending writes (e.g., a late addendum from the physician dictating a patient education note as they walk out) automatically route to an addendum note. The addendum is linked to the original encounter, carries AI-assist provenance, and never touches the signed note or the staff amendment.

Result: Clean claim. No denial. Complete audit trail with MA/provider attribution. Problem list updated. Staff edits preserved.

Technical Reference: ICD-10 Documentation Standards

The diabetic foot ulcer scenario above hinges on two ICD-10-CM codes reaching maximum specificity. Failing to code to the highest level of specificity is the single most common cause of claim denials in diabetic wound care, per CMS coding policy.

Required codes for this encounter:

• E11.621 - Type 2 diabetes mellitus with foot ulcer; L97.409 - Non-pressure chronic ulcer of unspecified heel and midfoot

• unspecified severity — L97.409 defaults to unspecified severity when documentation does not specify limited to skin breakdown, fat layer exposed, necrosis of muscle, or necrosis of bone

Why Both Codes Are Mandatory

ICD-10-CM convention requires dual coding for diabetic manifestations. E11.621 identifies the underlying condition (type 2 diabetes) with the manifestation category (foot ulcer). The ICD-10-CM Official Guidelines for Coding and Reporting (Section I.A.13) mandate an "additional code to identify the severity of the ulcer" from the L97 category. Omitting L97.409 triggers a denial because the claim lacks the manifestation specificity that payers require for medical necessity validation.

How Scribing.io Ensures Maximum Specificity

The severity level defaults to "unspecified" (the 9 in L97.409) only when the physician's documentation genuinely lacks tissue depth detail. Scribing.io does not fabricate specificity—this would constitute upcoding, a violation of the AMA CPT and ICD-10 coding ethics standards and would expose the practice to False Claims Act liability. Instead, the system prompts the physician: "Documentation does not specify ulcer depth. Confirm severity or dictate additional detail." This preserves the physician's clinical judgment as the final authority.

GAPI Note Object Architecture: Section Keys, Concurrency, and Failover

The GAPI Note Object is Greenway Intergy's proprietary API surface for programmatic note manipulation. Unlike FHIR's DocumentReference—which treats the note as a monolithic blob—the GAPI exposes discrete section keys that map 1:1 to the note template's structural elements.

Section Key Mapping

Concurrency Model

Each section key carries an independent version counter. This is critical: a write to hpi does not increment the version of assessment. Scribing.io exploits this granularity to allow the MA to edit ROS in Intergy's native UI while the physician simultaneously dictates the A/P through ambient capture—with zero collision risk between sections.

Within a single section, the version counter prevents lost writes. Scribing.io's merge-and-rebase logic operates as follows:

1. Read section content and version (v=3)

2. Construct the updated section content (append new dictation)

3. Submit write with If-Match: v=3

4. If GAPI returns 409 Conflict (version is now v=4 due to staff edit), re-read the section, diff against the expected base, merge non-conflicting changes, and retry with If-Match: v=4

5. If the diff reveals a true content conflict in the same paragraph, surface a resolution prompt to the clinician rather than choosing a winner silently

Addendum Failover Architecture

The addendum pathway activates when the GAPI returns a 423 Locked status (note signed). The addendum note object is created with:

• parentNoteId linking to the original signed note

• noteType: addendum

• Full section key availability—the addendum can carry its own CC, HPI, A/P sections if needed

• Provenance fields: authorType: AI-assisted, reviewedBy: [providerId], timestamp: [ISO 8601]

This preserves the legal integrity of the signed note while ensuring no clinical content is dropped. The addendum appears in Intergy's note history as a linked child document, visible during chart review and available for billing amendment if needed.

FHIR Condition Posting and Problem List Synchronization

FHIR Condition posting is the bridge between ambient documentation and revenue cycle integrity. A note can be clinically perfect and still produce a denied claim if the diagnoses live only in prose. Scribing.io's FHIR Condition posting follows the US Core Condition (Problems and Health Concerns) profile with Greenway-specific extensions.

Condition Resource Structure

Each posted Condition includes:

• code — Contains both the ICD-10-CM code (for billing) and the SNOMED CT concept (for interoperability), as mandated by USCDI v4

• clinicalStatus — Set to active for new diagnoses; recurrence if the patient has a prior resolved instance on their problem list

• verificationStatus — Set to confirmed only after the physician's verbal confirmation is captured by the diarization engine; never set to confirmed based solely on AI inference

• encounter — References the current encounter, ensuring the Condition is billable against this visit

• onsetDateTime — Extracted from the HPI ("started about two weeks ago" maps to an approximate date)

• recorder — References the provider, maintaining attribution

Problem List Deduplication

Before posting, Scribing.io queries the patient's existing Condition resources. If E11.621 already exists on the problem list from a prior encounter, the system updates the existing Condition's encounter reference rather than creating a duplicate. L97.409, as a new manifestation, creates a new Condition entry. This deduplication logic prevents the problem list bloat that plagues practices using tools without longitudinal awareness.

Billing Module Visibility

Intergy's billing workflow pulls diagnoses from the problem list, not from note text. By posting Conditions via FHIR before the physician finishes the encounter, Scribing.io ensures that when billing staff open the claim, the ICD-10 codes are pre-populated. The CMS billing compliance requirements for diagnosis-linked claims are met without manual intervention.

Citrix-Safe Performance: Sub-100 ms Streaming Without UI Automation

A significant percentage of Greenway Intergy deployments run on Citrix Virtual Apps (formerly XenApp) or Citrix Virtual Desktops. This creates a unique constraint: any tool that interacts with the EHR through screen scraping, keyboard injection, or Citrix ICA channel manipulation is inherently fragile and introduces security risks that most health system IT security teams will reject during vendor review.

Why UI Automation Fails on Citrix

• Latency variability: Citrix session responsiveness depends on network conditions, server load, and graphics rendering policy. A UI automation macro calibrated for 50 ms response time will misfire when latency spikes to 200 ms, inserting text into the wrong field or triggering an unintended save.

• Session multiplexing: Multiple clinicians sharing a Citrix server can experience session cross-talk when UI automation tools send keystrokes to the active window—which may not be the intended provider's session.

• Security policy conflicts: Citrix administrators enforce AppProtection policies that block screen capture and keystroke injection. UI automation tools trigger these policies, producing failed writes or lockouts.

• Upgrade fragility: Greenway's Intergy UI updates (field IDs, tab order, control names) break UI automation scripts with every patch. Maintaining these scripts becomes a perpetual engineering cost.

Scribing.io's API-Only Architecture

Scribing.io never touches the Citrix session. All write-back occurs through the GAPI Note Object's REST endpoints, which operate at the application server layer—below and independent of the Citrix presentation layer. This means:

• Zero Citrix dependency: Write-back performance is identical whether the physician accesses Intergy via Citrix, a local thick client, or a browser-based session

• No screen capture: Scribing.io does not read from or write to the Citrix display pipeline, satisfying HIPAA Security Rule minimum necessary access requirements

• Sub-100 ms streaming: The local stream buffer maintains a real-time transcript that commits to GAPI in batches every 80–100 ms. Even under GAPI rate limiting (429 responses), the buffer ensures the clinician never perceives a documentation lag because the UI is never involved

E/M Auditability: Diarization-Driven Medical Decision-Making Separation

The AMA/CPT E/M guidelines (2021 revision, current through 2026) base outpatient evaluation and management leveling on two components: total time or medical decision-making (MDM) complexity. When practices select the MDM pathway—as most do for established patient visits—the documentation must clearly demonstrate the number and complexity of problems addressed, the amount and complexity of data reviewed, and the risk of complications and/or morbidity.

The Diarization Requirement Competitors Miss

A competing tool that does not perform speaker diarization produces a note where the MA's intake questions and the physician's clinical reasoning are interleaved in a single narrative. An auditor reviewing this note cannot distinguish:

• Which problems were addressed by the physician (MDM element) vs. which were merely mentioned by the patient during intake

• Whether the data review (prior A1c results, wound culture) was performed by the physician or relayed by the MA

• Whether the risk assessment (decision to not hospitalize, prescription of wound care regimen) reflects physician judgment or AI-generated boilerplate

This ambiguity exposes the practice to E/M downcoding on audit—and under the OIG's False Claims Act enforcement, systematic E/M upcoding driven by AI documentation tools is an emerging compliance risk that the HHS OIG has flagged in its 2025-2026 Work Plan.

How Scribing.io Separates MA Intake from Provider MDM

Each attribution tag is stored as metadata on the GAPI Note Object section write and persisted in Scribing.io's audit log. If a payer or OIG audit requests documentation of who contributed what to the note, the practice can produce a timestamped, speaker-attributed record that maps every sentence to its source—something no free-text ambient tool can provide.

MDM Leveling Support

For the diabetic foot ulcer scenario, Scribing.io's structured output enables the following MDM analysis:

• Number/complexity of problems: Two active problems (E11.621 + L97.409), one of which is a new problem requiring additional workup → meets "moderate" threshold per AMA Table 2

• Data reviewed: Prior A1c lab result referenced, wound characteristics assessed → meets "moderate" data threshold

• Risk: Prescription drug management (silver sulfadiazine), decision for close follow-up rather than hospitalization → meets "moderate" risk threshold

• Resulting E/M level: 99214 (established patient, moderate MDM) — supported by discrete, attributed documentation rather than a narrative AI summary that an auditor must manually parse

See This in Action
Book a 15-minute technical demo to see concurrent, Citrix-neutral GAPI Note Object write-back with discrete CC/HPI/A/P mapping, addendum fallback on signature lock, and live FHIR Condition sync to the Intergy problem list. No slides. Live Intergy instance. Your encounter scenario.

→ Schedule your demo at Scribing.io