Signal/docs/compliance/fda-cds-exemption-memo-DRAFT.md

FDA Device Status Memo: Signal (DMEPOS Documentation Readiness Tracker)

DRAFT prepared for attorney review. Not legal advice.

Date	2026-07-06
Intended reviewer	Bittinger Law / Nixon Law Group (per Signal compliance checklist rows). NOTE for routing: 2026-06-05 session records name Clyde Mathes as attorney of record. Confirm the correct reviewer with Kisa before this memo is sent.
Prepared by	STTIL Solutions (lead-sttil), for KJF Professional Services LLC d/b/a STTIL Solutions
Compliance gate	First Supplier gate item: "FDA CDS exemption memo written and attorney-reviewed." This draft closes "written." "Attorney-reviewed" remains open until counsel signs off.
Status of legal claims	Every load-bearing legal claim below is tagged GROUNDED (verified against the cited statute or FDA guidance during preparation of this draft on 2026-07-06) or GRAFTED (assumption or characterization requiring attorney confirmation). Nothing in this memo is a legal conclusion. It is the argument prepared for counsel to confirm, correct, or reject.

---

1. Purpose and summary of position

This memo presents the argument that Signal, STTIL Solutions' documentation-readiness tracker for DMEPOS CGM suppliers, is not a medical device subject to FDA regulation. The primary position is that Signal never meets the device definition in section 201(h) of the FD&C Act because its intended use is administrative and billing support, a category Congress expressly carved out of the device definition in section 520(o)(1)(A). The Clinical Decision Support (CDS) exemption in section 520(o)(1)(E) is analyzed as a secondary frame, and this memo is candid that Signal does not fit that exemption's third criterion cleanly, which is exactly why the administrative position should lead.

2. What Signal does and does not do

Grounded in internal source documents: Signal repo CLAUDE.md ("What This Tool Does" and "PHI Architecture"), docs/compliance/data-handling.md (v1.0, 2026-06-07), and the Signal Compliance Readiness Whitepaper (2026-06-04, STTIL vault).

What it does. Signal is a B2B software tool sold to DMEPOS suppliers of continuous glucose monitors (CGMs). Supplier billing staff export order data from their existing DME order-management system as a CSV and upload it to Signal. For each patient record, Signal checks whether the payer's documentation requirements for reimbursement are satisfied: recency of the 6-month qualifying visit, prescriber PECOS enrollment, presence of a standard written order (SWO), and resupply eligibility timing. The output is a prioritized worklist that tells supplier billing staff which patient records have documentation gaps to resolve before claims are billed, so revenue does not leak to preventable documentation denials. Each worklist item carries a reason string showing the basis for the flag (the rule applied and the dates or fields it was computed from) and a rule version identifier.

What it sees. The calculation layer receives only: patient_id (the supplier's own internal MRN or account number, the sole crosswalk key), device type, shipment date or date of service, quantity, and payer, plus optional documentation-status fields (SWO status, visit date, PECOS verified, PA status, diagnosis-on-file yes/no flag) when the supplier chooses to include them (data-handling.md, Minimum Necessary Fields). The normalizer rejects and discards patient names, DOB, SSN, addresses, contact information, insurance member IDs, ICD-10 diagnosis codes, and clinical notes even if present in the uploaded file (data-handling.md, "What Signal Does NOT Accept"). patient_id is SHA-256 hashed before storage and in all logs. Raw CSV bytes are not retained.

What it does not do. Signal does not diagnose, treat, or recommend any clinical action. It does not read, receive, or analyze CGM sensor data, glucose values, or any physiological measurement of any kind. It does not contact patients or prescribers. It does not submit claims. It does not approve or deny anything. The clinical decision (a prescriber ordering CGM therapy) has already been made before any record reaches Signal. Signal's users are supplier billing and operations staff, not clinicians. Every action taken on a Signal flag is taken by a human staff member working in the supplier's own systems.

3. Regulatory framework

3.1 The device definition, FD&C Act section 201(h)

GROUNDED. 21 U.S.C. 321(h)(1) defines "device" as:

"an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is (A) recognized in the official National Formulary, or the United States Pharmacopeia, or any supplement to them, (B) intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or (C) intended to affect the structure or any function of the body of man or other animals"

and which does not achieve its primary intended purposes through chemical action or metabolism. The definition closes with: "The term 'device' does not include software functions excluded pursuant to section 360j(o) of this title." (Text verified 2026-07-06 against 21 U.S.C. 321(h)(1), Legal Information Institute, law.cornell.edu/uscode/text/21/321.)

Software is a device only if its intended use falls within (A), (B), or (C). Intended use is established by the manufacturer's claims, labeling, and promotion, which is why marketing discipline appears in section 6 as a live compliance control.

3.2 The administrative-support exclusion, section 520(o)(1)(A)

GROUNDED. Section 3060 of the 21st Century Cures Act (Pub. L. 114-255, December 13, 2016) added section 520(o) to the FD&C Act (21 U.S.C. 360j(o)). It provides that the term "device" shall not include a software function that is intended:

"(A) for administrative support of a health care facility, including the processing and maintenance of financial records, claims or billing information, appointment schedules, business analytics, information about patient populations, admissions, practice and inventory management, analysis of historical claims data to predict future utilization or cost-effectiveness, determination of health benefit eligibility, population health management, and laboratory workflow"

(Text verified 2026-07-06 against 21 U.S.C. 360j(o)(1)(A), govinfo.gov 2023 edition, and as reproduced in FDA's guidance "Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act," issued September 27, 2019, fda.gov/media/109622/download. That guidance states FDA "has not historically considered most of these software functions to be devices.")

3.3 The CDS exemption, section 520(o)(1)(E)

GROUNDED. Section 520(o)(1)(E) excludes from the device definition a software function that is not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system, and is intended for the purpose of:

"(i) displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines); (ii) supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and (iii) enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient."

(Text verified 2026-07-06 against 21 U.S.C. 360j(o)(1)(E), govinfo.gov 2023 edition.)

FDA's guidance "Clinical Decision Support Software" restates this as four criteria that must ALL be met: (1) no medical images, IVD signals, or signal-acquisition-system patterns as inputs; (2) displays or analyzes medical information; (3) supports or provides recommendations to a health care professional (HCP) about prevention, diagnosis, or treatment; (4) enables the HCP to independently review the basis so the HCP does not rely primarily on the recommendation.

Guidance currency, important. GROUNDED. The CDS guidance was finalized September 28, 2022 (87 FR 58732, Federal Register doc. 2022-20993, docket FDA-2017-D-6569). FDA issued an updated final guidance January 6, 2026 and re-issued it January 29, 2026; the January 29, 2026 document supersedes the earlier versions and is the operative text (verified 2026-07-06 against the guidance PDF cover page, fda.gov, and FDA's CDRH town hall transcript of March 11, 2026, fda.gov/media/191560/download). The statutory criteria did not change; FDA clarified its interpretation of "signal acquisition system," "pattern," and "medical information," and added an enforcement-discretion policy for functions that meet all criteria except that only one recommendation is clinically appropriate. Counsel should review against the January 29, 2026 text, not the 2022 text.

Correction to an internal document. The Signal Compliance Readiness Whitepaper (2026-06-04) paraphrased the CDS test with a fourth condition reading "relates to administrative or operational functions, not direct patient care decisions." That is not part of the 520(o)(1)(E) test. It conflates the CDS criteria with the separate 520(o)(1)(A) administrative exclusion. This memo uses the actual statutory text and the internal whitepaper should be corrected after attorney review.

4. Application to Signal

Position A (primary): Signal is not a device at all, because its intended use is administrative and billing support

GRAFTED as applied (the statutory texts are GROUNDED; their application to Signal is the argument for counsel to confirm).

Signal never enters the 201(h) definition. Its intended use, as designed, documented, and marketed, is to tell supplier billing staff whether payer documentation requirements are satisfied before a claim is billed. That is not "use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease" (201(h)(1)(B)), and it does not affect the structure or function of the body (201(h)(1)(C)). Software that checks paperwork completeness against reimbursement rules is in the same functional family as claims scrubbers, eligibility-verification tools, and billing-system edits, which have never been regulated as devices.

Independently, section 520(o)(1)(A) expressly excludes software intended for "administrative support of a health care facility, including the processing and maintenance of financial records, claims or billing information ... practice and inventory management, analysis of historical claims data ... determination of health benefit eligibility." Signal's function, verifying that documentation supporting a claim is complete and that a patient's resupply is payer-eligible, sits squarely within "claims or billing information" processing and adjacent to "determination of health benefit eligibility."

One honest gap in Position A: 520(o)(1)(A) speaks of a "health care facility." Whether a DMEPOS supplier is a "health care facility" for this purpose is not settled by anything reviewed in preparing this draft. GRAFTED: we assume a Medicare-enrolled DMEPOS supplier qualifies, or alternatively that the (o)(1)(A) examples evidence congressional intent that billing and claims software is not device territory regardless of the customer's corporate form. Counsel must confirm. Note that even if (o)(1)(A) were held inapplicable, Position A still stands on the simpler ground that Signal's intended use never satisfies 201(h) in the first place; (o)(1)(A) is reinforcement, not the foundation.

Position B (secondary): the CDS four-criteria analysis, taken honestly

Criterion by criterion against the January 29, 2026 guidance:

Criterion 1 (no medical images, IVD signals, or signal-acquisition patterns as inputs): MET. GRAFTED as applied. Signal ingests CSV rows of order-management data. It never receives CGM sensor output, glucose readings, medical images, or any physiological signal. This deserves emphasis because the word "CGM" appears throughout Signal's materials: a CGM is itself a signal acquisition system, and software analyzing CGM glucose data would fail criterion 1 and likely be a regulated device. Signal touches shipment and documentation records ABOUT CGM hardware orders, never the data stream FROM a CGM. The 2026 guidance's clarified definitions ("a system that measures a parameter from within, attached to, or external to the body for a medical purpose") confirm Signal's inputs are nowhere near this category.

Criterion 2 (displays or analyzes medical information about a patient): AMBIGUOUS, and the ambiguity favors Signal. GRAFTED as applied. The 2026 guidance interprets "medical information" as information used in, or relating to, the clinical care of the patient, of the kind generally communicated between HCPs in a clinical conversation (per the guidance and FDA's March 11, 2026 town hall). Signal's inputs (internal account number, device type, shipment date, quantity, payer, documentation-status flags) are order and billing metadata, not clinical-conversation content. If Signal's inputs are not "medical information," Signal is not CDS at all, which is consistent with, and supportive of, Position A: it is administrative software. The arguable exception is the visit date and the diagnosis-on-file flag, which relate to clinical events even though Signal uses them purely as documentation-requirement inputs. Counsel should weigh this.

Criterion 3 (supports or provides recommendations to an HCP about prevention, diagnosis, or treatment): NOT MET AS WRITTEN, and we should say so plainly. GRAFTED as applied. Signal fails this criterion in two directions. Its users are supplier billing and operations staff, not health care professionals acting in a clinical capacity. And its outputs are documentation-gap flags, not recommendations about prevention, diagnosis, or treatment of a disease or condition. The 2026 guidance interprets criterion 3 as software "intended for an HCP" that provides "condition, disease, or patient-specific information and options to an HCP to enhance, inform, and/or influence a health care decision." Signal informs a billing decision, not a health care decision.

The legal consequence of failing criterion 3 must be framed carefully: 520(o)(1)(E) is a carve-out from the device definition, so failing its criteria does not make software a device. It only means the CDS carve-out is not the applicable shelter. Software that fails criterion 3 because it makes no clinical recommendations to anyone is further from the device definition, not closer to it. This is why Position A leads and Position B is secondary.

Criterion 4 (independent review of the basis): SATISFIED IN SPIRIT. GRAFTED as applied. Every worklist flag carries a reason string stating the rule applied and the underlying dates and fields, plus a rule version identifier, and staff can verify every flag against the source records in their own order-management and billing systems, which remain the systems of record. If a regulator ever analyzed Signal under the CDS frame despite the criterion 3 mismatch, Signal's design meets the transparency and non-reliance purpose of criterion 4. The 2026 guidance's automation-bias discussion also cuts favorably: Signal's flags are worked in ordinary billing queues, not time-critical clinical settings.

Which argument is stronger

Position A is the primary argument: Signal is not a device because its intended use is administrative and billing support, outside 201(h), with 520(o)(1)(A) as express statutory reinforcement. Position B is the fallback frame if a regulator or counterparty insists on analyzing worklist flags as decision support, and it should always be presented with the criterion 3 candor above, never as "Signal qualifies for the CDS exemption" without qualification. Prior internal shorthand claiming "Signal meets all four conditions" overstates the CDS fit and should not be repeated externally.

5. Supporting facts

All GROUNDED in the cited internal documents and, where noted, verified against the codebase documentation.

1. Data minimization by architecture. Required fields are limited to patient_id, device type, shipment date, and payer, with quantity recommended and documentation-status fields optional (data-handling.md). The normalizer discards unrecognized columns and refuses names, DOB, SSN, contact information, member IDs, ICD-10 codes, and clinical notes even when suppliers include them.
2. patient_id is the sole crosswalk key. It is the supplier's internal account number. The supplier holds the identity crosswalk locally; it never reaches STTIL. patient_id is SHA-256 hashed before storage and in all logs (CLAUDE.md PHI Architecture; audit_logger.py per the compliance whitepaper).
3. No clinical measurements ever enter the system. No glucose data, no CGM sensor streams, no vitals, no images, no lab values. Raw CSV bytes are discarded after in-memory processing; only the hash and normalized records persist (data-handling.md, CSV Disposition Policy).
4. The user is billing and operations staff, not a clinician. Signal is B2B software operated inside the supplier's revenue-cycle workflow. No patient-facing surface exists.
5. No autonomous action. Signal does not contact patients or prescribers, does not submit claims, and does not conduct outreach. Staff decide what to do with every flag (CLAUDE.md: "Signal identifies gaps. It does not conduct outreach.").
6. Independent review is built in. Every flag shows its reason and rule version; the supplier's own systems remain the source of truth against which any flag can be checked.
7. The clinical decision precedes Signal. A prescriber has already ordered CGM therapy before any record exists for Signal to evaluate. Signal operates entirely in the post-prescription reimbursement-documentation layer.
8. Claims are scoped honestly. Signal measures documentation readiness rate. It does not claim to improve clinical outcomes, adherence, or clean-claim rate, and downstream claim improvement is never guaranteed in pitch, LOI, or training materials (standing STTIL scope rule).

6. Open questions and risks for the attorney

Listed weakest-first. These are the points a regulator or opposing counsel would push on.

1. WEAKEST POINT: output language that could be read as clinical. Signal's worklist flags include items like a 6-month qualifying visit that is out of date, and the pilot checklist confirms each status carries a "recommended action" string. A flag that effectively says "this patient needs a qualifying visit before resupply is billable" could be characterized as prompting a clinical encounter, that is, as influencing patient care rather than merely billing readiness. Our position is that the flag states a payer documentation requirement, not a clinical judgment, and the actor is billing staff coordinating paperwork. But the exact production strings matter. ACTION: counsel should review the live worklist status labels, reason strings, and every "recommended action" string verbatim, and STTIL should adopt a standing rule that action language is always documentation-framed ("payer requires a qualifying visit on file within 6 months of resupply") and never care-framed ("patient should see their doctor"). GRAFTED until that review happens.
2. "Health care facility" scope of 520(o)(1)(A). Whether a DMEPOS supplier qualifies is unresolved in this draft. GRAFTED. If counsel concludes it does not, Position A rests on the 201(h) intended-use analysis alone. We did not locate, and did not search exhaustively for, FDA statements applying (o)(1)(A) to suppliers rather than facilities; counsel should confirm.
3. Intended use is marketing-sensitive. Position A depends on intended use, and intended use follows claims. Any future marketing that frames Signal as preventing therapy interruption, improving adherence, or protecting patient health could be argued to create a 201(h)(1)(B) intended use. The win-win-win story must stay on documentation readiness and revenue protection. ACTION: counsel to bless a short list of permitted claim framings; STTIL's copy-review process then enforces it. GRAFTED.
4. Resupply-eligibility logic encodes payer clinical parameters. payer_rules.json contains payer coverage rules that reference clinical usage parameters such as sensor wear days and visit cadence. Our position is that applying a payer's published coverage criteria is billing eligibility work, the same work a human biller does with an LCD open on their desk. A hostile reading could call it clinical-rule computation. GRAFTED; counsel to confirm the characterization.
5. Guidance and statute currency. This memo was verified against the January 29, 2026 CDS guidance, the March 11, 2026 FDA town hall transcript, and the govinfo 2023 edition of 21 U.S.C. 360j (checked for the current text on 2026-07-06). FDA guidance in this space moved twice in 2026 already. ACTION: counsel to confirm no later revision at time of review, and STTIL's quarterly regulatory monitoring cadence should add the FDA CDS docket (FDA-2017-D-6569) alongside the existing CMS watch items.
6. Scope limitation and re-review triggers. This memo covers Signal as it exists on 2026-07-06. The following deferred or pipeline items would each require fresh analysis before build, and at least one would change the answer materially: Dexcom OAuth API integration (would ingest CGM signal data, failing CDS criterion 1 and putting the function in genuine device territory), document upload with AI validation, patient-facing SMS, Med Tracker, and any feature that scores or ranks patients on anything other than documentation status. The sttil-compliance-check gate already requires review before these; this memo should be cited in that gate.
7. Internal document correction. The 2026-06-04 compliance whitepaper's four-condition paraphrase of the CDS test is inaccurate (see section 3.3) and its "Signal meets all four conditions" conclusion is overstated. After counsel settles this memo, the whitepaper's FDA section should be rewritten to match, and the Signal CLAUDE.md checklist row updated from NOT DONE to reflect actual status. No external material should quote the old paraphrase.

7. Recommended attorney actions

1. Confirm or correct the primary position (not a device under 201(h); administrative software) and the decision to subordinate the CDS argument given the criterion 3 mismatch.
2. Rule on whether a DMEPOS supplier can rely on 520(o)(1)(A) as a "health care facility," or whether the position should rest on 201(h) intended use alone.
3. Review the production worklist status labels, reason strings, and "recommended action" strings verbatim against risk 6.1, and specify any required wording changes.
4. Approve a short permitted-claims list for marketing so intended use stays administrative (risk 6.3).
5. Confirm the memo's citations against the guidance and statute text current at the time of review, including any revision after January 29, 2026.
6. Advise whether this memo, once settled, should be reissued as a counsel letter suitable to hand to supplier compliance contacts and investors, which is the intended use of the final artifact.
7. Sign off so the First Supplier gate item "FDA CDS exemption memo written and attorney-reviewed" can move to done. The checklist is updated only after that sign-off, not on the strength of this draft.

---

Sources verified during preparation (2026-07-06)

• 21 U.S.C. 321(h)(1), device definition: law.cornell.edu/uscode/text/21/321
• 21 U.S.C. 360j(o)(1)(A) and (o)(1)(E), Cures Act software exclusions: govinfo.gov, USCODE-2023-title21, sec. 360j; also reproduced in FDA Section 3060 guidance below
• FDA, "Clinical Decision Support Software, Guidance for Industry and FDA Staff," issued January 29, 2026, superseding the January 6, 2026 issuance; originally finalized September 28, 2022 (87 FR 58732, docket FDA-2017-D-6569): fda.gov (guidance PDF verified from cover page)
• FDA CDRH Town Hall transcript, "Clinical Decision Support Software, Final Guidance," March 11, 2026: fda.gov/media/191560/download
• FDA, "Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act," September 27, 2019: fda.gov/media/109622/download
• Federal Register, "Clinical Decision Support Software; Guidance for Industry and FDA Staff; Availability," September 28, 2022: federalregister.gov/documents/2022/09/28/2022-20993
• Internal: Signal CLAUDE.md; docs/compliance/data-handling.md (2026-06-07); Signal Compliance Readiness Whitepaper (2026-06-04, STTIL vault); docs/production-readiness-whitepaper-2026-06-21.md

End of draft. Prepared for attorney review. Not legal advice.