Crosswalk Document

CMS-10558 Crosswalk.xlsx

Information Collection for Machine Readable Data for Provider Network and Prescription Formulary Content for FFM QHPs

Crosswalk Document

OMB: 0938-1284

Document [xlsx]
Download: xlsx | pdf

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
File Typeapplication/vnd.openxmlformats-officedocument.spreadsheetml.sheet
File Modified0000-00-00
File Created0000-00-00

© 2024 OMB.report | Privacy Policy