Response to Comment

Category
3rd party access

Comment Summary
Add data use agreement

Resolution
Out of scope for this document

3rd party access
3rd party access

Provide information on how CMS intends to use the information it
collects under this PRA
Create a contact registry for all third-party users

Out of scope for this document
Out of scope for this document

Burden

Increase burden estimates

Compliance

Treat as a trial or “soft rollout” year.

We have modified the burden estimates for
the data collection.
HHS Notice of Benefit and Payment
Parameters for 2016 establishes that 45 CFR
156.122(d)(1)(2) and 156.230(c) are effective
on January 1, 2016.

Compliance

CMS should have a requirement that all plans prominently list on
their directories an email address or phone number for members of
the public to directly notify the plan when provider directory
information is inaccurate, and a requirement that plans be
accountable for investigating these reports and modifying
directories accordingly in response

Out of scope for this document

Compliance

CMS should have a requirement that plans internally audit their
directories and modify directories accordingly based on audit
findings

Out of scope for this document

Compliance

CMS should have a requirement that plans contact providers listed
as in network who have not submitted claims within the past six
months to determine whether the provider still intends to be in
network.

Out of scope for this document

Compliance

CMS should have a requirement that plans honor provider directory
information

Data collected

Remove network tier from plans.json

Out of scope for this document
We propose collecting the network tier field
in order for issuers to distinguish between
types of providers

Data collected

Remove Drug Tier and Cost Sharing

Data collected

Remove plan contact

Data collected

Clarify that issuers need not include the names of hospital-based
providers in the JSON files

Data collected

clarify NPI use; make middle name optional

We believe collecting drug tier and cost
sharing information is important for
consumers and propose collecting drug tier
and cost sharing data
We propose collecting an email address in
order to contact issuer with questions about
the data.
We propose clarifying language that hospitalbased providers need not be included in the
JSON files
We propose clarifying language regarding
NPIs. CMS changed collection of middle name
to an optional field.

allow multiple addresses for providers

The JSON format allows for multiple
addresses for providers.

Data collected

Data collected

delete specialty field

Data collected

delete "accepting patients" field

We believe collecting provider specialty
information is important for consumers and
propose collecting specialty field.
We believe providing information about
whether or not a provider is accepting new
patients is important for consumers and will
collect that data.

Data collected

delete facility type

We propose collecting facility type in order to
aid consumers.

Remove drug-name

We propose collecting drug names in order to
aid consumers.

Remove quantity limits

We propose collecting information about
whether or not a formulary drug is subject to
quantity limits in order to aid consumers.

Remove drug tiers

We propose collecting drug tier information
in order to aid consumers..

Data collected

Data collected
Data collected

Data collected

Remove cost-sharing sub-type

Data collected

Include formulary URL

We propose collecting cost-sharing sub-type
in order to aid consumers.
We added an optional field to collect the
formulary URL displayed to consumers and
currently provided in the QHP certification
templates.

Data collected

Include formulary ID

Data collected

Remove "not less than monthly"

We propose collecting an optional field to
collect the formulary ID.
The requirement to collect provider data not
less than monthly is a regulatory requirement
and beyond the scope of this document. As
proposed in the Supporting Statement,
issuers would update formularies for
machine-readable purposes at least monthly.
As a point of clarification, the standard for
issuers' own websites is that formularies must
be up-to-date pursuant to
45CFR156.122(d)(1).

Data collected

Add date of last update to provider json

We propose adding a required field to collect
the date of last update.

Data collected

Add cost-sharing associated with the specific network or formulary
sub-type and network tiers

Data collected

Add physical accessibility of providers’ office

We propose collecting cost-sharing and
network tier information.
We will consider this comment for future
enhancements.

Data collected

Recommend RxCUI source be the same for prescription drug
template and updated regularly

Out of scope for this document

Data collected

Recommend issuers only show providers for the state where they
are offering coverage, plus bordering states where consumers could
cross borders for services

Out of scope for this document

Recommend no pharmacies or laboratories be included

We believe providing information about
pharmacies and laboratories is helpful for
consumers and propose including this

Data collected

information in the data collection.

Data collected

Recommend only 2016 plans display, not 2015 plans which might be
available through SEP

Data collected

Include specific descriptions of any available telemedicine services

HHS Notice of Benefit and Payment
Parameters for 2016 establishes that 45 CFR
156.122(d)(1)(2) and 156.230(c) are effective
on January 1, 2016.
We agree and have added an optional field to
capture whether telemedicine services are
available.

Data collected

Work with issuers to find out if claims payment systems or
databases could be used to obtain accurate and timely information
about which providers are in network

Out of scope for this document

Data collected

Allow future effective date providers

Data collected

Include primary care status indicator

Dental

Reporting on dental providers in this framework should be required
of both SADPs and major medical plans with “embedded” dental
benefits

We will consider this comment for future
enhancements and guidance.
We believe this indicator could cause
confusion due to the number of providers
who can be both primary and specialty
providers. We do not propose including a
primary care provider indicator.
SADPs must meet all QHP requirements
(except formulary requirements) unless
otherwise specified. This includes offMarketplace SADPs, as they are required to
be the same as on-Marketplace SADPs in
order to be certified. We expect SADP issuers
to adhere to machine-readable requirements
for off-Marketplace SADPs.

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

Dental

Stand-alone dental plans offering exchange certified off-exchange
policies should be exempt from the machine-readable requirements

Dental

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

We will consider this comment for future
enhancements.
SADPs must meet all QHP requirements
(except formulary requirements) unless
otherwise specified. This includes offMarketplace SADPs, as they are required to
be the same as on-Marketplace SADPs in
order to be certified. We expect SADP issuers
to adhere to machine-readable requirements
for off-Marketplace SADPs.
HHS Notice of Benefit and Payment
Parameters for 2016 establishes that 45 CFR
156.122(d)(1)(2) and 156.230(c) are effective
on January 1, 2016.

Guidance

CMS should provide guidance around what to do if there is no RxCUI
yet and provide a default value so that drug appears for consumer

Out of scope for this document

Integration

We urge CMS to look into creating integrated provider directory and
formulary capabilities for heatlthcare.gov as soon as possible

JSON
JSON

Out of scope for this document
We agree that the ability to find providers
proficient in languages other than English and
provider sex is important. We propose adding
Urges CMS to go further; reference a set of consumer protection
principles for provider directories, which may be helpful in terms of optional fields for language other than English
and provider sex to the JSON file. CMS will
implementing §156.230(b) and §156.122(d).3);
consider remaining suggested fields for future
http://consumersunion.org/wpcontent/uploads/2014/12/Provider_Directories_principles_1214.pdf enhancements.
After investigation, we determined that the
JSON file format is appropriate for this data
Change format to "XML or CSV format"
collection.

Standards will lead to consumer confusion due to (1) the enormous
challenges to maintaining and improving the accuracy and
timeliness of data; (2) the lack of standardized data definitions; (3)
the interplay between provider and formulary data and the benefit
designs and coverage rules of the associated QHPs; (4) the highly
compressed compliance and testing timelines leading up to open
enrollment for 2016; and (5) the potential for even greater
inaccuracies when third party software developers are given carte
blanche with issuers’ information
Questions about plan schema references

We propose including disclaimer language at
access points to the data.
We propose clarifying language.

Recommend specifying that the level of data files be at the issuer
level.

We believe that in order to provide adequate
information to consumers, data must be
collected at the plan level.

JSON
JSON

CMS should provide a data dictionary
Include control totals in each file

We agree with the importance of
understandable terms. We propose clarifying
language and examples in the JSON file.
Out of scope for this document

JSON

Qualifier values for copay and coinsurance fields are listed as nonrequired fields. These should be required fields

We agree with the commenter and propose
these qualifiers be required fields

JSON

The “machine readable” requirement should be more explicitly
defined as it pertains to the proposed schema. It should be stated
that to meet this requirement, a file should pass an agreed upon
schema validator. There’s already one configured for the propose
QHP schema: https://github.com/adhocteam/qhpvalidator

Out of scope for this document

JSON

For future maintainability, add a field that identifies the exact
version of the schema. Perhaps using describedBy field and
conformsTo fields, as is done for data.gov’s Common Core Schema.

We propose a required field to collect the
date of last update.

JSON
JSON

JSON

JSON

For the sake of consistency and minimizing confusion and
redundancy, consider using fields (and naming convention) already
in use from “adjacent” domains

We will consider this comment for future
enhancements.

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

We will consider this comment for future
enhancements.

JSON

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.

CMS does not contemplate using Medicare
Advantage plans for proof of concept.

Legality

This requirement seems to have no basis under Public Law 111-148
(cited in the Notice of Proposed Collection) as passed by Congress
and enacted in March 2010. A requirement IS created therein for
GAO Comptroller General to "conduct an ongoing study of Exchange
activities and the enrollees in qualified health plans offered through
Exchanges" to assess the ability of networks to support enrollees in
Federal Government health programs. However, this mandate upon
GAO doesn't appear to be assumed by CMS on GAO's behalf. CMS
CCIIO appears to be overreaching it's authority in requiring this
specific public disclosure by Issuers.

Out of scope for this document

Legality

The requirement for disclosure of Network and Formulary content
would appear to be discriminatory. The requirement is placed upon
Issuers of QHP coverage, with the presumed intent to protect and
serve those persons therein covered. HOWEVER, the requirement
ignores persons covered by Plans or Benefits NOT designated as a
Qualified Health Plans, but which are still subject to rules and
regulations promulgated by CMS. In this manner, it would appear
that CMS 1) ignores a large segment of the U.S. population who may
benefit from any analysis or enforcement resulting from the
disclosure requirement; 2) chooses to subject a minority of the U.S.
healthcare Issuer community and Plans to the requirement. CMS
should broaden it's perspective of what's important in investigating
and addressing presumed issues in the Insurance and Healthcare
reimbursement community to include ALL PLANS subject to CMS
regulation.

We considered broadening requirements for
formularies but believe we should see how
successful this implementation is, first. States
certainly have the option to create such
requirements for market wide plans. We do
not impose network adequacy requirements
on market-wide plans, which is why we did
not propose provider directory requirements
on them.

Legality

CMS again ventures far beyond the bounds of it's regulatory
authority in pushing forward with this requirement. While 45 CFR
156.230 (b) requires network content to be made available via the
Internet and written form, it makes no representation as to how
publicly available data files will meet the basic litmus of the title of
156.230 (c) Increasing consumer transparency. CMS seems wanton
to attempt for QHP Consumer Advocates what it cannot accomplish
for Medicare or Medicaid participants or their advocates, centralize
a database of allowable/contracted/network/reimbursable
providers. For that standpoint, it appears Medicaid and Medicare
participants are given short shrift, to the detriment of these more
needy populations.

Partnership
RxNorm update

Asks that CMS work with SBMs to implement a national standard
RxNorm should be updated on a monthly basis

Terminology

Clarify intended users “third-parties” or “software developers” or
“developers” or “marketplace consumers” or “enrollees”

CMS provided notice and comment
opportunities regarding this policy about this
provision in the Payment Notice. Medicare
Part D uses a similar tool in which enrollees
can enter their prescription drugs. We believe
this will be a useful tool for Marketplace
consumers.
Out of scope for this document; the Payment
Notice final9ized requirements for FFMs only
Out of scope for this document
The Payment Notice states that the purpose
of establishing machine-readable files with
this data would be to provide the opportunity
for third parties to create resources that
aggregate information on different plans, and
that a machine-readable file or format will
increase transparency by allowing software
developers to access this information and
create innovative and informative tools to
help enrollees better understand plan's
formulary drug lists and provider directories.

The Payment Notice states that the purpose
of establishing machine-readable files with
this data would be to provide the opportunity
for third parties to create resources that
aggregate information on different plans, and
that a machine-readable file or format will
increase transparency by allowing software
developers to access this information and
create innovative and informative tools to
help enrollees better understand plan's
formulary drug lists and provider directories.

Terminology

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).

Terminology

We also are not clear on the terminology of exactly what
information is being collected. In some places, the information to be
collected is with respect to formularies but other places refer to
formulary data, prescription formulary, formulary information or
formulary drug list. The final CMS rule at §156.120(d)(i) requires
plans to publish “a complete list of all covered drugs on its
formulary drug list.”

Terminology

We also strongly urge that CMS confirm that plans do not have to
include all formulations of drugs on the formulary.

We propose some modified language to
clarify the requirements.
We propose collecting drug information
based upon unique RxCUI, which includes all
drug formulations.

Terminology

Clarify whether Summary of Benefits and coverage is required (says
"Yes" instead of "Always."

We agree and have and propose the
requirement "Always."

Timing

CMS should complete analysis, design, development, and external
testing of JSON files and the interfaces with the new search field in
the healthcare.gov learning window by no later than the end of
August

Out of scope for this document

Finalize the PRA requirements as soon as possible

We agree with the importance of finalizing
the PRA and intend to finalize as soon as
possible within PRA process timeframes.

Timing

Timing

Recommend plans be given the opportunity to review how their
JSON data will appear on HealthCare.gov prior to November 1st

Timing

We seek a delay in effective date until 2017.

Timing

CMS could pilot this initiative and see how it works in a few states
for formulary drugs lists.

We agree with the importance of issuers
viewing and testing their data and propose
allowing issuers the ability to view their data
within the commenters timeframe.
HHS Notice of Benefit and Payment
Parameters for 2016 establishes that 45 CFR
156.122(d)(1)(2) and 156.230(c) are effective
on January 1, 2016.
HHS Notice of Benefit and Payment
Parameters for 2016 establishes that 45 CFR
156.122(d)(1)(2) and 156.230(c) are effective
on January 1, 2016.

Timing of data updates

We urge CMS to affirm that, as a general standard, consumer-facing
formulary drug lists need not be updated more frequently than
monthly and that implementation of formulary changes need not be
delayed while awaiting updates to consumer-facing lists...in
indicating that the machine-readable formulary
information need be updated no more frequently than once a
month, CMS acknowledges that it is not necessary for all publicly
available formulary information to be completely up-to-date at all
times

As proposed in the Supporting Statement,
issuers would update formularies for
machine-readable purposes at least monthly.
As a point of clarification, the standard for
issuers' own websites is that formularies must
be up-to-date pursuant to
45CFR156.122(d)(1).