Crosswalk Document

---

Overview

Comments
Comment Summary
Changes Summary

---

Sheet 1: Comments

Submitting Organization	Comment ID	Topic	Recommended comment reviewers	Comment/comment summary	Disposition of Comment
Health Detail	004	JSON	Ryan	The term "machine readable" is from the 1970s when computers had punch cards. Also, it is too ambiguous as, in theory, a machine can read most any type of format, though it may not be in a format that can be imported into a DB or analyzed ("non-structured"). The regulations go on to state that the format will be decided by HHS. If that is the case then we would strongly suggest that the format be general enough to provide enough differentiation for QHPs in the presentation of its different directories. (For provider directories, some QHPs have the ability to display one provider with many addresses, whereas others will display the same provider multiple times with the different addresses.) While the latter is not ideal, changing this would require significant investments in some cases. HHS requiring "XML or CSV format" enables the information to be imported into a database and analyzed, which we believe was the intent.	Reject
BCBSA	005	Data collected	Bill, PM (benefits)	Remove this field (network tier) from plans.json	Reject
BCBSA	005	Data collected	Bill, PM (Rx)	remove Drug Tier and Cost Sharing	Reject
BCBSA	005	Data collected	Bill, PM, Ryan	remove plan contact	Reject
BCBSA	005	Data collected	Bill, PM (benefits)	delete specialty field	Reject
BCBSA	005	Data collected	Bill, PM (benefits)	delete "accepting patients" field	Reject
BCBSA	005	Data collected	Bill, PM (benefits)	delete facility type	Reject
BCBSA	005	Data collected	Bill, PM (Rx)	Remove drug-name	Reject
BCBSA	005	Data collected	Bill, PM (Rx)	Remove quantity limits	Reject
BCBSA	005	Data collected	Bill, PM (Rx)	Remove drug tiers	Reject
BCBSA	005	Data collected	Bill, PM (Rx)	Remove cost-sharing sub-type	Reject
BCBSA	005	Data collected	Bill, PM (Rx)	Include formulary ID	Accept
BCBSA	005	Data collected	PM (Leigha)	Remove "not less than monthly"	Reject
BCBSA	005	3rd party access	PM (Leigha)	Add data use agreement	Reject
Delta Dental	006	Dental	Bill, PM (dental)	recommend that CMS consider the unique characteristics of dental providers when finalizing these fields. For example, “facility type” for a dental provider may be different than for other types of major medical providers. Specialty type is also unique for dental providers	Reject (consider for future)
PCMA	007	Terminology	PM (LAB)	Clarify intended users “third-parties” or “software developers” or “developers” or “marketplace consumers” or “enrollees”	Reject
PCMA	007	Terminology	Bill, PM	Recommend that CMS clarify that consumers do not have access to these files on the issuer’s websites. Consumers will not understand the information presented in this format (whether JSON or another format).	Reject
PCMA	007	3rd party access	PM (UNKN)	We also would appreciate information on how CMS intends to use the information it collects under this PRA (list of sample questions about use on page 4)	Reject
PCMA	007	JSON	Bill, Ryan	As an alternative to JSON, we would recommend any of the following formats: Medicare Plan Finder, .txt, or .csv. Unlike with JSON, there is wide industry experience with these other formats.	Reject
PCMA	007	Terminology	Bill, PM (Rx)	We also strongly urge that CMS confirm that plans do not have to include all formulations of drugs on the formulary.	Reject
PCMA	007	Data collected	Bill, PM (Rx)	We recommend deletion of quantity limits, as there is such a large range of what can be in place due to the drug safety considerations.	Reject
PCMA	007	Timing	Bill, PM	We seek a delay in effective date until 2017.	Reject
PCMA	007	Compliance	Bill, PM	We request that 2016 be treated as a trial or “soft rollout” year.	Reject
PCMA	007	Timing	Bill, PM	CMS could pilot this initiative and see how it works in a few states for formulary drugs lists.	Reject
PCMA	007	Timing	Bill, PM, Ryan	Another alternative would be to allow issuers to format the lists of formulary drugs the same as is done for the QHP submission, create a file format, and allow that format to be used (true non-duplication of effort). At the same time, CMS could undertake a pilot as well.	Reject
PCMA	007	Compliance	PM (Compliance)	If CMS insists on full implementation for 2016, then a good faith compliance standard should be used.	Reject
Community Catalyst	008	Data collected	Bill, PM	Add physical accessibility of providers’ office	Reject
United Concordia	009	Dental	PM (Leigha)	Stand-alone dental plans offering exchange certified off-exchange policies should be exempt from the machine-readable requirements	Reject
United Concordia	009	3rd party access	PM (UNKN)	CMS set conditions on third party access to ensure that the general public does not have access to the JSON files and develop standards that address limitations on third party use of the data	Reject (duplicate)
United Concordia	009	Dental	PM (Leigha)	If stand-alone dental plans are not exempt from this requirement then CMS should phase in the machine-readable requirements for “Exchange certified” dental networks starting in 2017	Reject
United Concordia	009	3rd party access	PM (UNKN)	CMS should clarify that making the information available does not provide the public with unrestricted access to the JSON files and confirm that only approved third party software developers have access.	Reject (duplicate)
United Concordia	009	3rd party access	PM (UNKN)	CMS should set conditions on third party access and develop standards that address limitations on the use of the data	Reject (duplicate)
United Concordia	009	3rd party access	PM (LAB)	CMS should address how a third party will be held accountable for inconsistencies between the issuer’s data files and what is posted on the third party’s website	Reject (duplicate)
National Association of Dental Plans	010	Dental	PM (Leigha)	Standalone dental plans offering “Exchange‐certified” dental policies off the Exchange, in the private market, should be exempt from the requirement to submit machine‐readable provider network data.	Reject (duplicate)
National Association of Dental Plans	010	Dental	PM (Leigha)	Phase in dental networks participating on Exchanges starting in 2017	Reject (duplicate)
AHIP	012	Data collected	Bill, PM, Ryan	Recommends that in year one, provider and Rx cost share not be included	Reject (duplicate)
AHIP	012	Data collected	Bill, PM, Ryan	Reduce the number of data elements in the plan file to simplify (list of suggested fields on page 3)	Reject (duplicate)
AHIP	012	Data collected	Bill, PM, Ryan	Remove email address for contact for errors	Reject
AHIP	012	Data collected	Bill, PM (beneftis,) Ryan	Remove network tier	Reject (duplicate)
AHIP	012	Data collected	Bill, PM (benefits and Rx), Ryan	Remove cost-sharing sub-type	Reject (duplicate)
AHIP	012	Data collected	Bill, PM, Ryan	Provide directory URL	Reject (duplicate)
AHIP	012	Data collected	Bill, PM, Ryan	Provide formulary URL	Reject (duplicate)
AHIP	012	Data collected	Bill, PM, Ryan	Reduce the number of data elements in the provider file (suggestions on pages 5 and 6)	Reject (duplicate)
AHIP	012	Data collected	Bill, PM, Ryan	Reduce the number of data elements in the drug file (suggestions on pages 6 and 7)	Reject (duplicate)
AHIP	012	JSON	PM, Ryan	Recommend formulary data be listed by formulary ID, then each plan can be associated with the proper formulary ID	Reject
AHIP	012	Timing	Bill, PM, Ryan	Recommend that for 2016 data collection happen with existing QHP templates (which AHIP called "machine readable") and institute JSON for 2017.	Reject (duplicate)
AHIP	012	Data collected	Bill, PM	Recommend no pharmacies or laboratories be included	Reject
AHIP	012	Data collected	PM (Rx)	Recommend plans not include all formulations of drugs on formulary	Reject (duplicate)
AHIP	012	JSON	PM (Rx)	Recommend plans have flexibility about how to populate non-preferred tiers of an open formulary, and that "default" drugs be sufficient for all non-preferred drugs	Reject (duplicate)
AHIP	012	Timing	Bill	Recommend that live links not be required before 10/15/2015 and that the date the links are required be provided by CMS as soon as possible.	Reject in part; accept in part (already allows) (duplicate)
AHIP	012	JSON	Bill, PM, Ryan	Recommend specifying that the level of data files be at the issuer level.	Reject
AHIP	012	3rd party access	Bill, PM, Ryan	Create a contact registry for all third-party users	Reject
Harvard Pilgrim	013	Timing	PM (UNKN)	Recommends implementation not before 1/1/2016	Reject (duplicate)
Harvard Pilgrim	013	Compliance	PM (Adam)	If implementation prior to 1/1/2016, requests safe harbor for year 1	Reject (duplicate)
Families USA	018	3rd party access	PM (UNKN)	Specifically, we believe that safeguards must be in place to ensure that third parties will use the most up-to-date versions of provider directories and formularies to populate their tools, and be held accountable for doing so, such as through user agreements they sign. At no point should third parties be using data that is less up to date than the data that issuers use to populate their provider directories and formularies, and issuers should be required to update their publicly available machine-readable files every 30 days	Reject (duplicate)
Families USA	018	JSON	Bill, PM, Ryan	Strongly support including “network tier,” but would recommend adding in example values of “tier 1, tier 2, tier 3,” to reflect common structures of network tiers	Reject
Families USA	018	Data collected	Bill, PM, Ryan	Physical accessibility of the provider’s facilities	Reject
AHIP	012	Data collected	Bill, PM	Allow future effective date providers	Reject (consider for future)
AHIP	012	Data collected	Bill, Ryan	Primary care status indicator	Reject
StrideHealth.com	020	JSON	Ryan	When formatted in a standardized, accessible manner, the data collection activities contemplated by this Notice create little to no additional burden on insurance carriers instead, we suggest mere reorganization of information already possessed and electronically organized by carriers. If that information is provided in a standardized format with the relevant context of the plans Summary of Benefits and Coverage, we believe they will be of maximum public utility	Reject
David Portnoy HHS IDEA Lab EntrepreneurinResidence	019	JSON		Fields specified by Medicare for a Model Provider Directory , consider adding these: i. plan.json 1. Description of plan’s service area 2. Customer service phone number 3. Customer service hours of operation 4. Network services: healthcare/vision/dental ii. provider.json 1. Provider type is defined more specifically: PCPs, Specialists, Hospitals, Skilled Nursing Facilities, Outpatient Mental Health Providers, Pharmacies (rather than Individual, Facility) 2. Neighborhood for larger cities (optional) 3. Provider website & email address (optional) 4. Provider supports eprescribing	Some reject (consider for future); some accept (already allows)
David Portnoy HHS IDEA Lab EntrepreneurinResidence	019	JSON		Besides JSON, consider giving plans an option to provide their submission in an HTML with microdata format. The reason is that for some, it’s advantageous to have both human and machine readable data in a single document, rather than needing to maintain synchronization between them. Webmasters might find microdata easier to work with than managing separate endpoints for JSON files. And microdata can still be validated and converted into JSON. (There are already many ways to extract JSON from microdata. For example, making an API call to http://rdftranslator. appspot.com/convert/microdata/jsonld/ <source_URL>)	Reject
David Portnoy HHS IDEA Lab EntrepreneurinResidence	019	JSON		I propose implementing a proof of concept on the proposed schema with Medicare Advantage plans, as a way to more adequately assess the burden and schema effectiveness, as well as serving as a concrete example for QHPs to follow.	Reject

---

Sheet 2: Comment Summary

Comment Category	Number of comments	Number of commentors	Commentors
JSON	28	12	AHIP, BCBSA, Clear Choice, Consumers Union, Delta Dental, Family USA, Health Detail, National Association of Dental Plans, PCMA, United Concordia, StrideHealth, David Portnoy
Dental	8	8	Delta Dental, United Concordia, National Association of Dental Plans
Timing of implementation	15	7	BCSA, Delta Dental, PCMA, United Concordia, AHIP, Harvard Pilgrim, Clear Choice
Data Collected	47	6	BCBSA, Community Catalyst, AHIP, Clear Choice, Families USA
3rd party access	11	5	AHIP, BCBSA, Family USA, PCMA, United Concordia
General Support	5	5	PCMA, FHA, AHIP, Clear Choice
Partnership (with state and industry)	4	4	PCMA, United Concordia, AHIP
Terminology in PRA	7	3	PCMA, Community Catalyst, Clear Choice
Compliance	7	3	PCMA, Harvard Pilgrim, Families USA
Burden	4	3	BCBSA, PCMA, United Concordia
Legality	3	3	Anonymous, Anonymous, Anonymous
Timing of updates	2	2	AHIP, PCMA
Vendor compliance	1	1	National Association of Dental Plans
RXNorm update by CMS	1	1	AHIP
Needed CMS guidance	1	1	AHIP
Integration with MA, etc.	1	1	Families USA
Total	145

---

Sheet 3: Changes Summary

Section Edited	Paragraph/page	Sentence	From	To	Reason
Developer Documentation Appendix A	2		Yes	Always	Comment to clarify
Developer Documentation Appendix A	2		N/A	Added Formulary URL field	Comment to include formulary URLs in JSON--optional
Developer Documentation Appendix A	3		network tier	Moved	Moved to network sub-type
Developer Documentation Appendix A	3		N/A	Added benefits field	Include to capture benefits array for subtypes
Developer Documentation Appendix A	3		N/A	Added last updated on field	track data updates from issuers
Developer Documentation Appendix A	3		drug tier	Moved	Moved to formulary sub-type
Developer Documentation Appendix A	5		N/A	Beneftis sub-type section	Comment to include benefits sub-type
Developer Documentation Appendix A	5		N/A	telemedicine	Comment to include telemedicine as an optional field
Developer Documentation Appendix A	5		Percentage	Rate	Improved terminology
Developer Documentation Appendix A	5		No	Always	Comment to require coinsurance qualifier
Developer Documentation Appendix A	7		Nothing	Plans	Make plans an array
Developer Documentation Appendix A	7		Nothing	Added last updated on field	track data updates from issuers
Developer Documentation Appendix A	8		Always	No	Make middle name optional
Developer Documentation Appendix A	8		N/A	Street Address	additonal field for better address collection
Developer Documentation Appendix A	8		string	array	specialty as an array
Developer Documentation Appendix A	8		Nothing	Gender	Comment to add gender of provider
Developer Documentation Appendix A	8		Nothing	languages	Comment to add languages spoken
Developer Documentation Appendix A	8		Nothing	Street Address	additonal field for better address collection
Developer Documentation Appendix A	11		formularies it is part of	plans that cover them	Improved terminology
Developer Documentation Appendix A	11		Formulary ID	Plans	Provide tie from drugs to plans
Developer Documentation Appendix B				Index Schema	Add schema for indexing