Response to 30-day comment (modified 9292015)

30 Day Public Comment Tracking Tool
Machine Readable Data for Provider Network and Prescription Formulary Content for
FFM QHPs
(CMS-10558)
Category

Comment Summary

3rd party
access

It is important that CMS and third party developers build
these tools so that they can be easily turned off if testing
reveals they are not functioning as designed.

3rd party
access

3rd party
access

3rd party
access
3rd party
access

3rd party
access

CMS should clarify how the machine-readable data will be
used
We are concerned third party developers may not be able
to identify and locate the full universe of issuer JSON files
for a given market...we recommend issuer's upload their
machine readable files directly to CMS via existing data
sharing channels and displayed on a CMS website.
We recommend that CMS develop a Disclaimer - User
Agreement that all third party vendors who are accessing
the web links of health plan files are required to sign. The
Agreement should address limitations on the use of the
data, require posting of common disclaimer language
wherever data is posted (language provided), legal
language (e.g., information is best available/not binding)
and considerations for when data is aggregated...should
include a hold harmless provision...request that CMS make
public of comment the proposed draft Disclaimer-User
Agreement.
CMS should create a registry system that contains the
contact information of the third-party vendors with whole
data use agreements will be signed
Only third parties or other members of the public who sign
the data use agreement should have access to the files
through a CMS managed website…(or) we recommend
CMS put in place the IT security controls to include the
ability to authenticate third parties that have sign the
usage agreements...we are concerned that bad actors
could cause denial of services by hitting public links
nonstop given the large file sizes.

Resolution
CMS intends to monitor
tool performance.
We expect software
developers to access this
information to create
tools to help enrollees

better understand the
availability of drugs and
providers in a specific
plan. This includes CMS
software developers
and tools on CMS
websites.
After investigation, we
determined that the JSON
file format is appropriate
for this data collection.

Outside the scope of this
document
Outside the scope of this
document

Outside the scope of this
document

30 Day Public Comment Tracking Tool
Machine Readable Data for Provider Network and Prescription Formulary Content for
FFM QHPs
(CMS-10558)

3rd party
access

Burden

Require that vendors show that they have no actual or
perceived conflict of interest in ownership or investors that
could impinge on an issuer’s competitive position; and
prohibit vendors from displaying or manipulating data in a
way that could give any issuer(s) a competitive advantage
over other issuers.

Data
collected

Provide more realistic burden estimates.
We recommend an alternative approach of the (formulary)
file layout that will not impact consumers or third party
data users but will avoid duplication and reduce potential
security risks. We recommend that the file include a
Formulary ID data element to organize drug information by
formulary which would be cross referenced in the plan's
JSON file. (sample developer document)

Data
collected

We recommend the optional field for telemedicine be
reconsidered for future years to allow time for further
discussion and the development of a standard definition.

Data
collected

We support the inclusion of a "last updated on" field in the
provider file. We recommend this reference the date on
which the data for the JSON file was created. As it is
proposed the last updated date is included for each
individual provider record which is not necessary.

Outside the scope of this
document
CMS has reviewed the
burden estimate and
determined it is
appropriate
CMS has considered this
comment and determined
that adding this additional
data element is not
necessary to prevent
duplicative efforts.
We believe that
information about
telemedicine is valuable
to consumers and are
including it as an optional
field.

Data
collected

The "last updated on"
field is the last date for
which the provider or
drug information was
updated.
CMS is not collecting data
We recommend that accepting new patients field is moved at this level at this time,
to the plans sub-type, which would permit an issuer to
but may consider for
reflect that a particular provider is accepting patients for
future releases. CMS will
one QHP and not another, similar to how network tier is
provide clarifying
represented (where a provider may be in different network language in the guidance
tiers across QHPs.)
documents.
…we request that Provider Network Tier, Drug Tier an
HHS Notice of Benefit and
dCost Sharing, Accepting Patients, Facility type, Quantity
Payment Parameters for
Limits, Cost Sharing Sub-type, Telemedicine, Provider sex,
2016 establishes that 45
languages, etc. be moved back a year to allow issuers and
CFR 156.122(d)(1)(2) and
CMS to address any potential issuers prior to adding
156.230(c) are effective
additional data elements.
on January 1, 2016.

Data
collected

We support the inclusion of a plan contact email
address…however, we do not support releasing (it) for
consumers an developers to report what they believe to be
errors.

Data
collected

The Plan Contact
information will be
available through the
publically accessable JSON

30 Day Public Comment Tracking Tool
Machine Readable Data for Provider Network and Prescription Formulary Content for
FFM QHPs
(CMS-10558)
file, but will not be
available on the user
interface

Data
collected

We recommend...modifying plans.json, providers.json, and
drugs.json – generally by removing data elements, but in
some cases adding data elements – to provide the
minimum data necessary for assisting consumers.

Data
collected

Do not require issuers to include the names of facilities
that establish relationships only with providers, not
patients, such as labs performing pathology services.

Data
collected

Do not require issuers to include all formulations of
drugs...Including every drug formulation will require a
greater level of effort, which will significantly increase the
burden detailed in the information request.

Data
collected

In provider.json, add "Organization" as third type of
provider (INDIVIDUAL, FACILITY, ORGANIZATION)

Data
collected

Add schema version fields that enables future
maintainability and data integrity.

We have consider all
comments regarding data
to include in the JSON file
and have determined that
all items requested are
necessary
CMS is accepting this
comment. CMS will
provide clarifying
language in the guidance
documents.
We have considered this
comment and determind
that issuers should include
all RxCUIs, which includes
all drug formulations
CMS will consider for
future versions
CMS has considered this
comment and determined
that data integrity is
maintained with an
existing "updated on"
field.

30 Day Public Comment Tracking Tool
Machine Readable Data for Provider Network and Prescription Formulary Content for
FFM QHPs
(CMS-10558)

Guidance

DDPA is concerned that the Information Request adversely
impacts SADPs that are not participating in the
Marketplaces. The Information Request published on June
26, 2015 indicated that “SADPs must meet all QHP
requirements” and that CMS “expects SADPs issuers to
adhere to machine-readable requirements for offMarketplace SADPs.” The Final Notice of Benefit and
Payment Parameters published in February of 2015 made
no mention of any such requirement. Further, the final
regulation from which HHS seeks to assert the authority to
promulgate this requirement is limited to issuers in the
FFMs. 45 CFR 156.230(c). With only a few months until
open enrollment begins, it seems disruptive to press this
requirement on Off-Marketplace SADPs. Issuers have made
the choice not to offer these SADPs on the Marketplaces
and imposing this operational requirement this late is
counterproductive to the intent of the rule which is to
benefit consumers. At a minimum, DDPA recommends
postponing the enforcement of the machine readable
requirements on Off-Marketplace SADPs until the next
open enrollment period.
We recommend that CMS within the next two weeks
release technical guidance addressing the URL submission
process.
We recommend that for this year's submission CMS use
the same (RxCUI) source and version that is required for
the priscription drug template (November 3, 2014, full
monthly release of RxNorm) and that that version be
updated on, preferably, a monthly basis to ensure that
monthly updates for the posted machine readable
formulary remain in sync with changes or new drugs
introduced to the market over the course of the year.

Guidance

Clarify Rx supplies, such as diabetic test strips, which have
no Rx CUI.

Outside the scope of this
document
CMS will provide clarifying
language in the guidance
documents.

Guidance

Provide clarifying language regarding NPIs...the utilization
of NPIs is not perfect (e.g. providers may have multiple
NPIs or submit bills under an institutional NPI).

CMS will provide clarifying
language in the guidance
documents.

Guidance

Specify guidelines for accessing JSON files to avoid
exorbitant expenditures on hardware and bandwidth that
issuers might otherwise have to make. For example,
vendors may have to request and comply with schedules
and maintenance downtimes from issuers.

Outside the scope of this
document

Dental
Guidance

CMS is accepting this
comment.
Outside the scope of this
document

30 Day Public Comment Tracking Tool
Machine Readable Data for Provider Network and Prescription Formulary Content for
FFM QHPs
(CMS-10558)

Integration

DDPA recommends CMS reconsider these issues and
within the next two weeks release technical guidance
addressing...If CMS plans to create a master list of plan
websites, the ability for health plans to preview this list to
ensure that their links are displaying correctly and are
functional.
We recommend that all plans be displayed in the plan
results page , including plans that do not include a drug or
doctor selected by the consumer and that CMS
recommend the same approach is used for third party
users.
CMS should clarify the language that will be used when the
selected doctor or drug is not displayed with the plan
results.
If the logic to suggest searches for generic options along
with brand name drugs is not implemented similar to
Medicare, we suggest that educational language be
included to alert consumers to search both generic and
brand drug names.

JSON

We recommend the data (web links) is provided at an
issuer level to reduce the number of separate files that are
posted.

JSON

Additional guidance for whether there should be separate
JSON files for providers and practitioners

JSON

If a particular method is expected or required, clarify how
to support multiple addresses for a provider. (1. duplicate
the entire provider object for each address, 2. send
additional 'address' objects within a provider object or 3.
send a list of 'address' objects instead of a single one
within a provider object.)

JSON

Recommends using API in lieu of the JSON file

Guidance

Integration
Integration

Outside the scope of this
document

Outside the scope of this
document
Outside the scope of this
document

Outside the scope of this
document
The JSON file format
supports web links at
multiple levels. CMS will
provide clarifying
language in guidance
documents.
The JSON file format
supports providers and
practioners in either the
same or in separate files
and CMS will provide
clarifying language in
guidance documents
The JSON file format
supports multiple
addresses for issuers by
duplicating the provider
object for each address.
CMS will provide clarifying
language in guidance
documents.
We have considered all
comments and
determined that a JSON
format is appropriate.

30 Day Public Comment Tracking Tool
Machine Readable Data for Provider Network and Prescription Formulary Content for
FFM QHPs
(CMS-10558)

JSON

JSON
JSON
JSON

We recommend CMS consider creating a central website
for insurers to load their machine-readable files and where
third parties can go to capture all insurers' files.

Create a third (provider) type, “Pharmacy.”
In provider.json, show array of network affiliations, add
specialty, add NetworkID. (Please reference commenter's
document)
In plans.json, add Network ID based on each 14-digit plan
ID

JSON

Recommend to add a new entity: networks.json . This
entity could be optional for now, but is a more accurate
and concise way to describe real world insurance coverage
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
proposed QHP schema:
https://github.com/adhocteam/qhpvalidator.

JSON

DDPA recommended CMS consider the unique
characteristics of dental providers when finalizing the
provider schema. Specifically, DDPA noted that the “facility
type” for a dental provider may be different than for other
types of major medical providers.

JSON

After investigation, we
determined that the JSON
file format is appropriate
for this data collection.
We have considered this
comment and will not
create a third provider
type, "Pharmacy."
However, issuers may split
their JSON files however
they wish. CMS will
provide clarifying
language in the guidance
documents.
CMS will consider for
future versions
CMS will consider for
future versions
CMS will consider for
future versions

CMS has considered this
comment and we will not
require schemas to pass a
schema validator.
CMS has considered the
unique characteristics of
dental providers and
determined that the
current schema can be
used.

30 Day Public Comment Tracking Tool
Machine Readable Data for Provider Network and Prescription Formulary Content for
FFM QHPs
(CMS-10558)

Legality

Policy

...the proposed information collection does not
satisfy...“minimize the Federal information collection
burden” and “maximize the practical utility of and public
benefit from information collected by or for the Federal
Government.” 44 U.S.C. § 3504(c)(3), 4)...(and)...“using
plain, coherent, and unambiguous terminology,” so that
they are “understandable to those who are to respond”
and to ensure that information collections are “consistent
and compatible, to the maximum extent practicable, with
the existing reporting and recordkeeping practices of those
who are to respond.” 5 C.F.R. § 1320.9(d), (e).
Disagrees that the machine-readable file will be most upto-date information when it is only updated monthly. "The
best source for an up-to-date provider directory is the
issuer's own site, which links directly to the provider
directory.

Terminology

Release common data definition for Summary URL…delete
the field to avoid the display of incorrect cost sharing
information for those eligible for reduced cost sharing
Release common data definition for "Array" of
Providers…individual practitioner information and facility
information , as is the case with the QHP templates with
network adequacy information or…at the group practice
level or both?

Terminology

Release common data definitions for Specialty & Facility
Type; recommend that CMS recommend (but not require)
Healthcare Provider Taxonomy Code Set

Terminology

Define "third-parties," "software developers,"
"developers," "marketplace consumers," and "enrollees."

Terminology

There is…mention of a "machine-readable URLs" (sic) and
it is unclear what this is referencing.

Terminology

Terminology

Terminology

Identify the enumerated values to use for “Facility Type”.
Consider using the same vocabulary as in Network
Adequacy Template.
Enumerated values throughout the Cost Sharing subtype
should be defined more specifically: pharmacy_type,
copay_opt, coinsurance_opt. While examples are given, it’s
not clear whether they define the entire vocabulary.
Consider using the same vocabulary as used for Plans &
Benefits Template .

CMS has considered this
comment and determined
that the PRA complies
with 44 U.S.C. § 3504(c)(3)
and 5 C.F.R. § 1320.9(d), €
Machine-readable data
files are expected to be
updated not less than
monthly.
The summary URLs are
collected for the standard
plan variant ("01"). CMS
will provide clarifying
language in guidance
documents.
CMS will provide the
definition for "Array" of
providers in the guidance
documents.
Outside the scope of this
document
Outside the scope of this
document
CMS will provide clarifying
language in the guidance
documents.
CMS will provide clarifying
language in guidance
documents.
CMS is accepting this
comment. CMS will
provide clarifying
language in guidance
documents.