Currentsanford health planPolicy 1.0

HIPAA Transaction Standard Companion Guide (276/277)

Customize your policy alerts

Sign up for sanford health plan Policy 1.0 alerts

Get alerted when Policy 1.0 changes without checking for updates manually.

Monitor payer policy activity

Receive email alerts as soon as relevant payer policies are published or updated.

Defines Sanford Health Plan's supplemental implementation and transmission rules for ANSI ASC X12 276/277 (005010X212) Health Care Claim Status Request and Response transactions and applies to EDI trading partners who submit or receive these transactions with SHP.

Policy Summary

Payersanford health plan

PolicyHIPAA Transaction Standard Companion Guide (276/277)

Policy CodePolicy Policy 1.0

Change TypeNo material changes

Effective Date

Last ReviewFeb 28, 2017

Next Review Date

Key ActionTrading partners must complete Trading Partner Registration and submit the Trading Partner Agreement and EDI Agreement to Sanford Health Plan to register for testing and use HTTPS connectivity.

SourceLink

POLICY UPDATE CHANGES

No material clinical or coverage changes in this revision.

10maximum test transactions

Mon-Friregistration assistance hours

HTTPSconnection protocol

real-timesupported mode

12 monthsclaim status window

8 charsSubmitter ID limit

Operational Coverage & Processing Criteria

inv-01: Trading Partner Operational and Testing Criteria

Operational and testing requirements for trading partners transmitting 276 requests and receiving 277 responses.

Submitters must have Internet (HTTPS) connection capability to submit 276 requests and receive 277 responses.

The submitter must be associated with at least one provider in the Sanford Health Plan provider database; system supports inquiries for registered providers only.

Only real-time 276 inquiries are supported.

Trading partners must complete basic transaction submission testing for each X12 transaction type and demonstrate ability to receive acknowledgments and responses via HTTPS.

Data integrity for testing is determined by SHP's TR3 editor; testing cannot progress until the trading partner's data receives no TR3 edit errors.

Trading partners must complete an agreed test plan (including volume and acceptance ratios) and satisfy the test plan before transition to production.

When test results have satisfied the test plan and the Trading Partner Agreement has been executed, the trading partner's submission status is changed from test to production.

SHP Operations will establish logons, passwords and a HIPAA transaction mailbox for each trading partner approved for testing.

If retransmission of files is required, SHP support personnel will confirm necessity and provide specific information to the trading partner.

Trading Partner Registration assistance is available Monday - Friday, 9:00 AM to 5:00 PM CST; trading partners must enroll and submit required agreements to register for testing and production.

inv-02: COVERAGE CRITERIA

Key acceptance and processing criteria for trading partners and transaction submissions:

Trading partners must complete testing per an agreed test plan and demonstrate zero TR3 edit errors before production transition.

SHP will validate that trading partners are approved; only transactions from submitter IDs on file will be accepted and transmissions with invalid submitter IDs will be rejected.

Real-time testing and production endpoints (SOAP and MIME URLs) will be provided for Real-time submissions.

Use ID Qualifier 'ZZ' in ISA05/ISA07; use the SHP-provided Submitter ID in ISA06 and GS02. Submitter IDs are limited to 8 characters with a leading alpha prefix (P = Production, T = Test).

Allowed ISA delimiters: '*' = element delimiter, ':' = composite delimiter, '~' = terminator, '^' or '{' = repetition (ISA11).

GS enveloping: Submitter = GS02, Receiver = GS03; SHP will assign Sender IDs as specified.

Claim status information is current as of the creation date/time of the 277 response; SHP returns claim status only for dates of service within the past twelve months and will return 'claim not found' for requests older than twelve months.

All line items (start and end service dates) must fall within the requested date period for a claim to be selected. Specific matching criteria (Claim ID, submitted charges) take precedence; otherwise, claims matching general criteria (dates, servicing provider) will be selected.

276 Real-Time requests must be limited to one patient per ISA-IEA, GS-GE and ST-SE envelope configuration; one Real-Time request per ST or GS will be accepted.

All HIPAA 5010 TR3 technical requirements must be met; responses are returned with appropriate STC segments or the transaction is rejected in a 999 report.

Specific 276 field rules include: NM108 = 'PI' for Information Source, NM109 use 00370 or 00870 with value '46' for Information Receiver/ETIN, NM108/NM109 use 'XX' for Service Provider NPI, subscriber identifiers and formats (DMG02 = CCYYMMDD) and use 'MI' for subscriber identifier qualifier.

Specific 277 field rules include: NM108 = 'PI' for Information Source, NM109 returned values mirror 276 identifiers (00370/00870 value 46), ETIN and NPI returned in NM segments, and STC segments used to convey service line status.

SHP will not send a 999 acknowledgement upon successful receipt of a 276. If a transmission is rejected, a 999 Rejection will be issued and may include Level 1 and Level 2 errors; Level 2 editing will be performed.

SHP support will confirm necessity and provide information when retransmission of files is required.

Standards, Transactions, and Claim Status Limits

Transaction and receiver codesmixed

005010X212	Responsible Agency Code Version/Release/Industry Identifier Code for transaction sets
46	Application's Receiver Code / value returned for Information Receiver Name

Claim status date range

Claim status date rangeRequests return claim status only for dates of service within the past 12 months; requests >12 months return 'claim not found'.

Selection criteriaAll line items (start and end service dates) must fall within the requested date period to be selected for response.

Matching logicIf a claim matches specific criteria (Claim ID or Claim Submitted Charges) it is selected; otherwise claims matching general criteria (dates, servicing provider) are selected.

Multiple matchesIf multiple matches are found within the same date range all matching claims will be returned (may occur due to split claims).

Authorization requirementClaim status returned only if the submitter requesting the status is authorized by the servicing provider on the 276 request.

Onboarding, Registration, and Testing Actions for Trading Partners

Documentation Required

Complete Trading Partner Registration and Submit Agreements

Trading partners must complete the Trading Partner Registration (TPR) form and print, complete, and return the Trading Partner Agreement (TPA) and Sanford Health Plan Trading Partner EDI Agreement (Appendix A and Appendix B) to Sanford Health Plan (address provided) before partner testing or use of HTTPS connectivity can begin.

Complete Trading Partner Registration (TPR) form.
Print, complete and sign Trading Partner Agreement (TPA) and Sanford Health Plan Trading Partner EDI Agreement (Appendix A).
Return original documents to: EDI Trading Partner Agreement & Registration, Sanford Health Plan, 300 CHERAPA Pl Ste 201, Sioux Falls, SD 57103.

Note

Contact SHP for Onboarding

Providers, billing services, and clearinghouses must contact Sanford Health Plan to begin submitting 276/277 transactions using the provided phone numbers for onboarding and support.

Call (877) 305-5463 or (605) 328-6868 to initiate onboarding for 276/277.
Use these contacts to arrange testing and obtain operational assistance.

Prior Authorization

Satisfy Test Plan and Ensure Valid Submitter IDs Before Production

Transition from test to production requires that test results satisfy the agreed test plan and that the Trading Partner Agreement has been executed; SHP will only accept transactions from valid trading partners whose submitter IDs are on file and will reject transmissions with unvalidated submitter IDs.

Provide a submitter ID that SHP has on file and validated before production submissions.
Satisfy all test plan requirements (including TR3 validation) prior to status change from test to production.

Key Terms and Environment Identifiers

SHP EDI trading partner

DefinitionSHP EDI trading partner: any business partner (provider, billing service, software vendor, employer group, financial institution, etc.) who transmits to or receives electronic data from SHP.

Registration requirementTo register, trading partners must complete the Trading Partner Registration (TPR) form and the Trading Partner Agreement (TPA).

Document submissionBoth original TPR and TPA documents must be returned to Sanford Health Plan EDI Trading Partner Agreement & Registration (address provided in guide).

Submitter ID

ISA Sender/Submitter ID useThe Submitter ID provided by SHP in the Trading Partner Agreement must be used in ISA06 and GS02.

ID length and prefixSubmitter ID limited to 8 characters with a leading alpha prefix (P = Production, T = Test).

Real-Time ISA patternFor 276 Real-Time submissions the ISA Sender ID uses the TR0XXXXX or PR0XXXXX pattern as shown in examples.

Delimiters

Element delimiter* = Element Delimiter

Composite delimiter: = Composite Delimiter

Terminator delimiter~ = Terminator Delimiter

Repetition delimiters (ISA11)^ or { = Repetition Delimiter (ISA11)

Environment prefixes

Test/Production prefixesPrefix 'T' = Test and 'P' = Production for ISA Sender IDs and Submitter ID prefixes.

Real-Time variantsReal-Time ISA Sender ID variants use 'TR' and 'PR' (examples: TR0XXXXX or PR0XXXXX).

Envelope usagePrefix conventions apply to ISA Sender ID for both batch (e.g., T00XXXXX/P00XXXXX) and Real-Time examples; Submitter ID uses matching leading alpha prefix.

Policy Summary

Payersanford health plan

PolicyHIPAA Transaction Standard Companion Guide (276/277)

Policy CodePolicy Policy 1.0

Change TypeNo material changes

Effective Date

Last ReviewFeb 28, 2017

Next Review Date

SourceLink

On This Page

OpenPayer is powered by Trek Health's payer performance platform. Trek continuously ingests, validates, and normalizes Transparency in Coverage data alongside payer policies and other commercial payer data to create a structured payer intelligence foundation. OpenPayer uses this foundation to deliver personalized search results, dynamically generated policy pages, and tailored policy monitoring based on each user's payers, specialties, billing codes, and areas of interest. The same intelligence powers broader payer performance workflows, including reimbursement benchmarking, contract evaluation, payer negotiations, and financial decision-making.