Getting Patient Registration Right at a Place Like MGH
Patient registration is one of those areas that gets treated like it is simple because every hospital has done it for decades. It is not simple. At a place like MGH, where you are moving thousands of encounters a day across multiple buildings and service lines, the registration step is where the entire workflow either holds together or starts falling apart. I have watched systems go sideways from registration errors that nobody caught until the patient was already in imaging holding for three hours. The core issue at MGH and similar large academic medical centers is that patient registration is no longer a single desk job. It spans self-service kiosks, phone intake, emergency department pre-registration, outpatient scheduling, insurance verification APIs, and identity matching across multiple EHR instances. Get any one of those touchpoints wrong and the downstream impact compounds fast. I learned this the hard way during a project where we tried to clean up duplicate MRNs in the registry. The EHR was flagging about four percent of new registrations as potential matches. The standard deduplication rules checked name, DOB, and sex. That should be enough. It is not. We ran into a case where a father and daughter shared the exact same date of birth because the hospital recorded the date as the estimated due date rather than the actual birth date for a newborn. The system merged them. The daughter's chart ended up with the father's medication list and allergy history. We had to spend two full days doing manual reconstruction and a formal merge audit. After that I started adding last known address and phone number as a tertiary match field. It cut false merges down to below one percent.
How The Registration Flow Actually Works In Practice
At MGH the registration process generally moves through these stages. First there is identity capture, either through the patient portal pre-registration, a kiosk in the clinic, or front desk intake. Second is insurance and demographic verification, which hits the payer API in real time. Third is the registration creation in the EHR, which generates the MRN or links to an existing one. Fourth is scheduling linkage so the encounter can actually occur. The piece everyone underestimates is the third stage. MRN assignment and duplicate resolution is where most of the hidden rework lives. If your system does not have a solid probabilistic matching engine, you will accumulate duplicates. And duplicates are expensive. A single duplicate pair can create separate billing records, split lab results across two charts, and generate phantom appointment no-shows that skew wait time metrics. One practical workaround that saved us months of headache was building a pre-registration hold zone. When the EHR flags a potential duplicate match above a certain confidence threshold, the registration is held in a staging area rather than auto-created. A trained registrar reviews the flags, checks photo ID if needed, and either approves the merge or creates a new record with a documented reason. This added about twenty seconds per flagged registration but reduced post-creation duplicate resolution work by roughly eighty percent. It also made audit trails much cleaner because you could see exactly when and why a merge decision was made.
Insurance Verification As A Workflow Bottleneck
Real-time eligibility checks through APIs like Availity or direct payer connections are supposed to solve coverage problems before the patient walks in. They do not fully solve them. At MGH we saw a pattern where payer APIs returned active status for a plan but then denied the claim at adjudication because of a prior authorization requirement that the API did not surface. The registration looked clean. The claim died two weeks later. The fix was not technical. It was procedural. We started requiring registrars to query the specific procedure's authorization status through the provider's own prior auth portal, not just the general plan eligibility API. This added about a minute per registration but cut our prior auth denial rate from about nine percent to under three percent. It is a small friction point that pays for itself quickly when you consider the revenue cycle impact.
Get the Full Details
Self-Service Kiosks And What Goes Wrong
Kiosks sound like the answer to front desk bottlenecks. They reduce face-to-face intake time and let patients update their own demographics. In practice they introduce a different set of failures. Patients skip fields. They enter partial addresses. They select the wrong payer because the screen showed a plan name that did not match their insurance card exactly. I spent a week tracking kiosk registrations and found that roughly fifteen percent had at least one demographic field that required follow-up correction before the encounter could proceed cleanly. The workaround was implementing mandatory field validation with real-time feedback rather than letting the kiosk submission pass through with soft warnings. If the address is missing a street suffix, the kiosk flags it before the patient submits. If the insurance ID format does not match the expected pattern for that payer, it asks for re-entry. This shifted the correction burden from post-registration cleanup to the kiosk moment itself. The tradeoff is slightly longer kiosk time per patient, roughly thirty to forty-five extra seconds on average, but it reduces downstream rework significantly.
Registration Data Quality And What It Actually Means
Data quality in registration is not about having perfect fields. It is about having the right fields populated at the right time for the downstream process. For billing, you need a valid tax ID and subscriber relationship code. For clinical workflows, you need a confirmed phone number and preferred pharmacy. For research registries, you need consent flags and demographic accuracy. Trying to capture everything at registration is unrealistic. Patients do not know their tax ID offhand. They do not always remember their preferred pharmacy. A pragmatic approach is tiered data capture. Core identifiers and insurance go in first. Clinical support data and secondary contact info gets requested through the portal before the visit or collected during check-in. Consent and research flags are handled as separate touchpoints. This breaks the registration process into logical segments instead of one giant form that nobody reads carefully.
What Still Breaks
No registration system is bulletproof. The biggest remaining failure point at large institutions is cross-entity identity matching. MGH shares patients with Brigham and Women's, numerous community hospitals, and solo practice groups. When a patient registers at one site and has previously been registered at another with a slightly different name spelling or old address, the matching engines sometimes fail to link them. This creates duplicate charts across the health system, not just within a single hospital. The workarounds here are limited. You can improve matching confidence scores, add manual merge queues, and invest in master patient index tools, but you will never eliminate cross-institution duplicates entirely. It is a structural problem that requires ongoing governance, not a one-time system fix. Another persistent issue is emergency department registration bypass. ED patients often register under incomplete information because the clinical need takes priority. Their demographics get filled in later, sometimes days later, and the lag creates problems for bed management, transfer coordination, and reporting. There is no clean solution here other than accepting that ER registration will always be less accurate than elective intake and building your workflows around that reality.
Where To Start If You Are Rebuilding This
If you are looking at overhauling your registration workflow, do not start with technology. Start with the failure modes. Map out every place where a registration error has caused a downstream problem in the last year. Billing denials. Duplicate chart merges. Hold times in radiology. Missing prior auth flags. Those pain points tell you where to invest. A well-tuned matching engine matters more than a shiny kiosk. Real-time insurance verification with denial reason routing matters more than a pretty patient portal. And a clear merge governance policy matters more than any single vendor feature. The registration step is not glamorous. It is not where clinicians spend their time. But it is where the entire patient journey either runs smoothly or hits friction at every subsequent touchpoint. Getting it right is mostly about removing avoidable errors and accepting that some imperfection will always remain.
