San Francisco Health Plan EDI Requirements: 270/271 Transactions Payer Specific Rules and Limitations
San Francisco Health Plan EDI Requirements described below regard to all parties taking part in EDI process with San Francisco Health Plan. San Francisco Health Plan uses real time processing for its EDI transactions to provide immediate responses to its submitters. San Francisco Health Plan EDI Requirements demand that in real time, the submitter transmits a request transaction to San Francisco Health Plan and then remains connected while San Francisco Health Plan processes the transaction and responds to the submitter.
According to San Francisco Health Plan EDI Requirements, San Francisco Health Plan accepts the 270/271 transactions as a “read only” transaction and will not use any data coming in on the 270 transaction to update its internal systems. Additionally, where stated in the ASC X12N ANSI 270/271 Health Care Eligibility Inquiry and Response Transaction Set Implementation Guide, San Francisco Health Plan will respond with its source data from internal systems, including but not limited to such data as Subscriber Name information, Member Id and DOB.
San Francisco Health Plan EDI Requirements – Supported Functionality
To provide immediate response to submitters, San Francisco Health Plan uses real time processing for its EDI transactions. To uniquely identify a member, a 270 transaction must include the member’s San Francisco Health Plan’s Identification Number, the information source’s Identification Number, member’s last name, date of birth and service type code. For the best response time, San Francisco Health Plan EDI Requirements state that the 270 transaction set be programmed to a single record. This consists of a one-to-one ratio in a single loop structure: one information receiver, one provider, one subscriber and request service type code(s). If the 270 transaction is not rejected, San Francisco Health Plan returns the 271 transaction with all of the Inquiry criteria information that was submitted in the 270 transaction.
For members where a gap in coverage exists, the following scenarios may apply:
- When a single Plan Date is provided on a 270 request and this date falls within a non-covered period, the 271 response will include an AAA segment with an error code of 75.
- When a Plan Date range is provided on a 270 request and the entire date range falls within a non-covered period, the 271 response will include an AAA segment with an error code of 75.
- When a Plan Date range is provided on a 270 request which overlaps covered and non-covered eligibility periods, only 271 responses will be provide for the covered periods and an error code will not be returned.