Reference 360 Versus Lookup Fields for Regulated Code Sets
CareFirst Health Plan uses Customer 360 for 4.2 million members and 180,000 providers. It currently stores 18 code sets as lookup fields inside business entities: country, state, language, gender, provider specialty, NAICS industry, and others. Each business entity has its own copy of the lookup values, and adding a value requires a deployment. A regulatory change introduces new provider specialty codes with a two-year crosswalk to legacy codes; two regions will adopt the change at different dates. Analytics needs to join member and provider data by specialty and compare old and new codes. Some lists are tiny and static, such as gender and yes/no. Others are externally governed and versioned. The team has limited deployment windows and wants to reduce release coupling.
1. Which code sets should move to Reference 360, and which should remain lookup fields? Give criteria for the decision.
Read the worked answer
Move code sets to Reference 360 when they are shared across business entities, externally governed, versioned, effective-dated, or need crosswalks. Provider specialty, NAICS, country, and state fit: they change on external schedules, are reused by member and provider domains, and analytics needs consistent values. Keep lookup fields for small, static, internal lists such as gender or yes/no, where a separate reference dataset adds overhead without governance benefit. A practical test: if adding a value currently requires a deployment and more than one entity needs the list, it is a candidate for Reference 360. If the list is stable and used by only one field, keep it as a lookup. Also consider ownership: a code set with no business owner and no external standard may be better as a lookup until governance exists. The trade-off is more up-front modeling and syndication work versus less release coupling and consistent cross-domain reporting.
2. How would you model versions, effective dates, and crosswalks for the specialty code change so that Customer 360 and analytics stay consistent?
Read the worked answer
Model the specialty code set in Reference 360 with versions: legacy version, new version, and an effective date per region. Store crosswalk rows mapping old code to new code, including many-to-many mappings and a confidence or status flag for ambiguous mappings. Do not overwrite the legacy code on existing member or provider records; keep the historical value and add the new value with effective dating. Syndicate the reference data to Customer 360 so validation uses the correct version by region and date. For analytics, publish both the original code and the mapped new code, plus the crosswalk version, so reports can reconcile. Test region-specific effective dates and a record that spans the transition. Trade-off: retaining history and crosswalks increases storage and join complexity, but overwriting destroys auditability and makes trend analysis impossible.