Patient intake software that writes into the chart

Why intake should write to the chart rather than a PDF

Most intake tooling produces a completed PDF, which the front desk then retypes into the practice management system. That retyping is where transposed policy numbers and misspelled names enter the record, and those errors surface weeks later as rejected claims.

Intake in MegAligna writes structured fields instead. Demographics land as demographics, the payer block lands in the shape billing reads later, and each consent is stored as a signed, versioned document attached to the patient.

What ships with intake

How the forms themselves are defined

Intake forms are template definitions, not a drag-and-drop builder. A form is a version-pinned definition your practice’s pack carries; assigning one points at that exact version and keeps pointing at it, so a form signed last March reproduces today exactly as the family saw it. A builder that lets anyone edit a live consent form is a builder that quietly changes what somebody agreed to.

Fields available today are short text, long text, dates and single-select. Conditional questions — show this only if that was answered — are not built, so a form asks everyone the same questions and the irrelevant ones are left blank.

Specialty variants ride the pack, so an ABA intake and a chiropractic intake are different definitions rather than one form with branches.

The forms themselves have a starting point: the patient intake form template sets out what a first-visit packet should collect and why. Where intake hands off afterwards is covered in the patient portal.

What intake has to capture for billing to work later

Intake is where most billing problems are created, months before anyone sees a denial. Four fields do disproportionate damage when they are collected loosely:

• The member ID exactly as printed on the card, alpha prefix included. This becomes Box 1a of the claim, and a transcribed ID missing its prefix is one of the highest-volume rejections there is — chased weeks later by someone who cannot see the card.
• Which policy is primary. Where a second plan exists, the coordination of benefits has to be established at intake rather than inferred at billing time. A claim that puts the secondary in the primary position comes back.
• Release of information and assignment of benefits. These are the two consents behind Boxes 12 and 13 of the CMS-1500 form. “Signature on file” is only acceptable where the practice actually holds one, which means the packet has to capture it and the chart has to keep it.
• The referral, where the payer requires one. A referral sitting in a fax tray is not a referral on the claim.

Collected as structured fields, these arrive in the shape billing needs. Collected as a scanned PDF, they arrive as an image somebody retypes — and every retyping is a chance to drop a prefix.

When the patient is a child

Across paediatrics, ABA, early intervention and school-based therapy, the person completing intake is almost never the person being treated, and that changes the form rather than just the tone.

The record has to hold two or three people at once: the patient, the insured, and whoever is legally able to consent — who may be neither of the others. On the claim, the patient in Box 2 and the insured in Box 4 are different people, and crossing them is routine in paediatric billing precisely because intake collected them as one.

It also means consent is a question with a legal answer rather than a signature box. Which parent or guardian may consent, what happens in a shared-custody arrangement, and who is entitled to see the record afterwards are all things a first-visit packet has to establish while it is easy, rather than during a dispute.