monthly list of deactivated NPIs<\/strong>. We can load it into our own table and search that table, so a visit never calls out to anything.<\/p>\nImport<\/strong> (scripts\/import-npi.php<\/code>, run on a monthly timer, then weekly for updates):<\/p>\n\n- Stream the CSV inside the zip. The full file is about 9 GB with 300+ columns, so read it row by row and keep only what we use.<\/li>\n
- Keep individuals<\/strong> (entity type 1) whose practice location is in Texas<\/strong>, plus organisations<\/strong> (entity type 2) with a pharmacy taxonomy (
3336*<\/code>), which covers E1 as well.<\/li>\n- Columns to keep: NPI, last\/first\/middle name, credential, primary taxonomy (shown as specialty), practice address, city, ZIP, phone, fax, deactivation date.<\/li>\n
- Upsert by NPI. Mark deactivated NPIs inactive rather than deleting them, so an old visit still resolves to the doctor it named.<\/li>\n
- New table
npi_provider<\/code> via migrations\/<\/code>. It holds only public data, so it is stored in plaintext with no PHI. Index it on (last name, first name) and ZIP.<\/li>\n<\/ul>\nLookup<\/strong> (\/do\/npiSearch<\/code>, gated like the visit screens):<\/p>\n\n- Staff type a last name and optionally a first name, and can narrow by city or ZIP. We return up to about 20 matches showing name, credential, specialty and city. Staff pick one, address and phone fill in, and staff can still edit them.<\/li>\n
- Searching by name alone isn't precise enough for common surnames. Narrowing by city or ZIP fixes that. Defaulting to the client's own ZIP would also work, and it is safe because the search stays on our server.<\/li>\n
- Store the NPI<\/strong> with the answer, not just the address text, so we can trace which record was picked.<\/li>\n<\/ul>\n
Why a download beats the API:<\/strong> nothing about the client, not even the doctor's name, leaves our server. Production needs no outbound access at visit time. Search speed doesn't depend on CMS being up. The weekly update file keeps us at most a week behind the registry.<\/p>\nThe open question for the customer still applies: if they keep their own list of doctors, we could load it into the same table as an extra source.<\/p>\n"}