For PBMs / Payers - Populating the 271

🟩 audience pbms/payers this content is intended for pharmacy benefit managers (pbms), payers, and organizations supporting pharmacy benefit operations one eligibility response (271) can support both v3 0 and v60 ehrs simultaneously rather than sending separate messages, populate both the v3 0 and v60 identifiers in the same 2110c1 loop ehrs on v3 0 use the legacy identifiers, while v60 ehrs use the newer identifiers to maintain compatibility during migration, surescripts uses the v60 identifiers and translates them for ehrs that have not yet upgraded pbm quick reference (populate this / get that) you populate… with… so that… ref element 2 (ref02) on fo, cli, ig, als your existing v3 0 identifiers v3 0 ehrs resolve coverage ref element 3 (ref03) on fo, cli, ig, als the four v60 ref borne file ids (pe, pa, pn, st) v60 ehrs resolve those four files one msg segment per remaining v60 file 2 char type code + file id in msg01 v60 ehrs resolve all other files ref n6 bin (iin) + pcn — unchanged never moves what every pbm must do 1\ keep sending your v3 0 identifiers in ref element 2 (ref02) do not move or remove them these are what v3 0 ehrs read ref fo element 2 = formulary status id ref cli element 2 = coverage list id (your consolidated coverage identifier) ref ig element 2 = copay id ref als element 2 = alternatives id ref n6 = bin (iin) and pcn — unchanged; these never move 2\ add your v60 file identifiers in ref element 3 (ref03) for the four files that ride in ref segments existing ref segment element 2 (v3 0, keep) element 3 (add for v60) ref fo formulary status id product exclusion (pe) file id ref cli coverage list id prior authorization (pa) file id ref ig copay id pharmacy network (pn) file id ref als alternatives id step therapy products (st) file id 3\ add msg segments for every other v60 file, one segment per file the first two characters of msg01 are the file type code; the remaining characters are the file id msg type code v60 file ag alternative product groups al age limits gl gender limits ql quantity limits sm step therapy product groups sp specialty products ps copay product specific gm general message me message pc pharmacy chain 4\ reuse one identifier value across every file it covers if, in v3 0, a single coverage list file backs several coverage rules (age, gender, quantity, prior authorization, product exclusion, step therapy, specialty), send that same value in each corresponding ref03 / msg field this is what lets surescripts collapse the granular v60 files back into your single v3 0 coverage list for v3 0 ehrs 5\ constrain the two translatable ids to 10 characters formulary status id ( ref fo element 2) and alternatives id ( ref als element 2) must be ≤10 characters so they remain valid v3 0 identifiers after translation all other v60 file ids may be up to 40 characters 6\ reuse your existing v3 0 file identifiers wherever the file persists for files that exist in both v3 0 and v60 (prior authorization, quantity limits, age limits, gender limits, step therapy, etc ), send the same file id you already use new file ids are only needed for the v60 list types that did not exist in v3 0 decision summary your situation what to send single coverage file backs many rules (typical v3 0 pbm) one value in ref02 of ref cli , repeated across all coverage ref03/msg fields distinct file per rule (granular v60 pbm) each file's own id in its ref03 / msg field; still populate ref02 for v3 0 file exists in both standards reuse the existing v3 0 file id file is new in v60 (e g , specialty products, alt product groups) assign a new id; ≤40 chars absence rule (important) a pbm that has not upgraded sends only ref02 values, with no ref03 and no msg segments surescripts treats the absence of ref03/msg as a v3 0 only sender (for how a receiving system maps a v3 0 only 271 into granular requests, see the on demand formulary integration guidance )