Patient Demographic and Insurance Data
Accurate registration data drive claims, safety, and reporting. The master patient index (MPI) is the facility's list of patients and their unique identifiers; duplicate or overlapped records cause wrong-patient errors, claim denials, and safety events. Core demographic fields include legal name, date of birth, sex, address, phone, preferred language, race/ethnicity, and guarantor information. Verify identity using at least two identifiers; never rely on room number or diagnosis.
Insurance data include the subscriber (the person who holds the policy), the patient's relationship to the subscriber, member ID, group number, plan type, and payer ID. The subscriber is not always the patient: a child may be covered under a parent's plan. Coordination of benefits (COB) determines primary and secondary payers. For dependent children covered by two parents' plans, the birthday rule often makes the parent whose birthday falls earlier in the calendar year primary, but the exact rule depends on the plan and state. Medicare Secondary Payer rules, workers' compensation, and auto liability can change the primary payer. Verify eligibility before the visit and re-verify when the plan changes. Obtain prior authorization or referral when required, and document assignment of benefits and consent.
Common traps: entering the subscriber's date of birth as the patient's; missing a middle name or suffix that causes a duplicate; failing to ask about other coverage; and assuming an insurance card guarantees active coverage. Red Flags Rule training helps staff recognize identity theft indicators.
Worked example: A mother brings in a child covered by the father's policy. The registration specialist records the father as subscriber, the child as patient, relationship 'child,' and verifies the member ID and group number. The child's own date of birth, not the father's, goes in the patient demographic field.
Rule of thumb: Verify eligibility and identity at every visit; small data errors become large denials.
EHR Technology and Reporting
EHR technology questions focus on how systems capture, share, and report data-and where users can compromise integrity. An EHR is a longitudinal record with clinical decision support (CDS), computerized provider order entry (CPOE), e-prescribing including controlled substances (EPCS), results management, and a patient portal. An EMR is typically a single organization's record; an EHR is designed to share across settings. Interoperability depends on standards such as HL7, FHIR, and CCD/CCDA documents, and on health information exchange (HIE) agreements. Promoting Interoperability (formerly meaningful use) rewards secure exchange, e-prescribing, and patient access, but the program rules change, so rely on current program guidance.
Security features include role-based access, unique user IDs, audit logs, encryption, and automatic logoff. Audit logs must be retained and reviewed; they are not edited by users. Downtime procedures are essential: staff need a way to document and reconcile data after an outage. Copy-and-paste and cloned notes create documentation integrity risks; templates should prompt original content. Clinical decision support can improve care but also cause alert fatigue.
Reporting depends on structured data. Quality measures, registries, and dashboards draw from discrete fields, not free text. If a value is entered in a note instead of a structured field, it may not be reportable. Data validation, mapping, and reconciliation are part of reporting governance.
Worked example: A clinic wants to report a hemoglobin A1c quality measure. The value must be captured in a structured, coded field with the correct date; a scanned PDF or narrative note may not be computable. The analyst validates the query against the EHR data dictionary before submitting.
Rule of thumb: If it is not in a structured, validated field, it cannot be reliably reported.