forked from jmandel/interop-2019-nprms
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathCMSs.html
8181 lines (8181 loc) · 587 KB
/
CMSs.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html><html>
<head>
<title></title>
<style type="text/css">
<!--
.xflip {
-moz-transform: scaleX(-1);
-webkit-transform: scaleX(-1);
-o-transform: scaleX(-1);
transform: scaleX(-1);
filter: fliph;
}
.yflip {
-moz-transform: scaleY(-1);
-webkit-transform: scaleY(-1);
-o-transform: scaleY(-1);
transform: scaleY(-1);
filter: flipv;
}
.xyflip {
-moz-transform: scaleX(-1) scaleY(-1);
-webkit-transform: scaleX(-1) scaleY(-1);
-o-transform: scaleX(-1) scaleY(-1);
transform: scaleX(-1) scaleY(-1);
filter: fliph + flipv;
}
-->
</style>
</head>
<body>
<a name=1></a><b>Notice: </b>This HHS-approved document has been submitted to the Office <br/>
of the Federal Register (OFR) for publication and has not yet been placed <br/>
on public display or published in the Federal Register. The document <br/>
may vary slightly from the published document if minor editorial changes <br/>
have been made during the OFR review process. The document <br/>
published in the Federal Register is the official HHS-approved document. <br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
[Billing Code: 4120-01-P]<b> </b><br/>
<b>DEPARTMENT OF HEALTH AND HUMAN SERVICES </b><br/>
<b>Centers for Medicare & Medicaid Services </b><br/>
<b>42 CFR Parts 406, 407, 422, 423, 431, 438, 457, 482, and 485 </b><br/>
<b>Office of the Secretary </b><br/>
<b>45 CFR Part 156 </b><br/>
<b>[CMS-9115-P] </b><br/>
<b>RIN 0938-AT79 </b><br/>
<b>Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; </b><br/>
<b>Interoperability and Patient Access for Medicare Advantage Organization and Medicaid </b><br/>
<b>Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care </b><br/>
<b>Entities, Issuers of Qualified Health Plans in the Federally-facilitated Exchanges and </b><br/>
<b>Health Care Providers </b><br/>
<b>AGENCY: </b>Centers for Medicare & Medicaid Services (CMS), HHS.<b> </b><br/>
<b>ACTION: </b>Proposed rule. <br/>
<b>SUMMARY: </b>This proposed rule is intended to move the health care ecosystem in the direction <br/>
of interoperability, and to signal our commitment to the vision set out in the 21st Century Cures <br/>
Act and Executive Order 13813 to improve access to, and the quality of, information that <br/>
Americans need to make informed health care decisions, including data about health care prices <br/>
<hr/>
<a name=2></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>2</b> <br/>
and outcomes, while minimizing reporting burdens on affected plans, health care providers, or <br/>
payers. <br/>
<b>DATES</b>: To be assured consideration, comments must be received at one of the addresses <br/>
provided below, no later than 5 p.m. on <b>[</b>Insert date 60 days after date of publication in the <br/>
<b>Federal Register]</b>. <br/>
<b>ADDRESSES: </b>In commenting, please refer to file code CMS-9115-P. Because of staff and <br/>
resource limitations, we cannot accept comments by facsimile (FAX) transmission. <br/>
<br/>
Comments, including mass comment submissions, must be submitted in one of the <br/>
following three ways (please choose only one of the ways listed): <br/>
1. Electronically. You may submit electronic comments on this regulation to <br/>
<b>http://www.regulations.gov</b>. Follow the "Submit a comment" instructions. <br/>
<br/>
2. By regular mail. You may mail written comments to the following address ONLY: <br/>
<br/>
Centers for Medicare & Medicaid Services, <br/>
Department of Health and Human Services, <br/>
Attention: CMS-9115-P, <br/>
P.O. Box 8016, <br/>
Baltimore, MD 21244-8016. <br/>
Please allow sufficient time for mailed comments to be received before the close of the comment <br/>
period. <br/>
3. By express or overnight mail. You may send written comments to the following address <br/>
ONLY: <br/>
<br/>
Centers for Medicare & Medicaid Services, <br/>
<br/>
Department of Health and Human Services, <br/>
<br/>
Attention: CMS-9115-P, <br/>
<hr/>
<a name=3></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>3</b> <br/>
<br/>
Mail Stop C4-26-05, <br/>
<br/>
7500 Security Boulevard, <br/>
Baltimore, MD 21244-1850.<b> </b><br/>
For information on viewing public comments, see the beginning of the "SUPPLEMENTARY <br/>
INFORMATION" section. <br/>
<b>FOR FURTHER INFORMATION CONTACT: </b><br/>
Alexandra Mugge, (410) 786-4457, for issues related to interoperability, CMS health IT strategy, <br/>
technical standards and patient matching. <br/>
Natalie Albright, (410) 786-1671, for issues related to Medicare Advantage. <br/>
John Giles, (410) 786-1255, for issues related to Medicaid. <br/>
Emily Pedneau, (301) 492-4448, for issues related to Qualified Health Plans. <br/>
Meg Barry, (410) 786-1536, for issues related to CHIP. <br/>
Thomas Novak, (202) 322-7235, for issues related to trust exchange networks and payer to payer <br/>
coordination. <br/>
Sharon Donovan, (410) 786-9187, for issues related to federal-state data exchange. <br/>
Daniel Riner, (410) 786-0237, for issues related to Physician Compare. <br/>
Ashley Hain, (410) 786-7603, for issues related to hospital public reporting. <br/>
Melissa Singer, (410) 786-0365, for issues related to provider directories. <br/>
CAPT Scott Cooper, USPHS, (410) 786-9465, for issues related to hospital and critical access <br/>
hospital conditions of participation. <br/>
Lisa Bari, (410) 786-0087, for issues related to advancing interoperability in innovative models. <br/>
Russell Hendel, (410) 786-0329, for issues related to the Collection of Information or the <br/>
Regulation Impact Analysis sections. <br/>
<hr/>
<a name=4></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>4</b> <br/>
<b>SUPPLEMENTARY INFORMATION: </b><br/>
Inspection of Public Comments:<b> </b>All comments received before the close of the comment period <br/>
are available for viewing by the public, including any personally identifiable or confidential <br/>
business information that is included in a comment. We post all comments received before the <br/>
close of the comment period on the following Web site as soon as possible after they have been <br/>
received<a href="http://www.regulations.gov/">: http://www.regulations.gov. F</a>ollow the search instructions on that Web site to view <br/>
public comments. <br/>
<b>I. Background and Summary of Provisions </b><br/>
A. Purpose<b> </b><br/>
<br/>
This proposed rule is the first phase of proposed policies centrally focused on advancing <br/>
interoperability and patient access to health information using the authority available to the <br/>
Centers for Medicare & Medicaid Services (CMS). We believe this is an important step in <br/>
advancing interoperability, putting patients at the center of their health care and ensuring they <br/>
have access to their health information. We are committed to solving the issue of interoperability <br/>
and achieving complete access to health information for patients in the United States (U.S.) <br/>
health care system, and are taking an active approach to move participants in the health care <br/>
market toward interoperability and the secure and timely exchange of health information by <br/>
proposing and adopting policies for the Medicare and Medicaid programs, the Children’s Health <br/>
Insurance Program (CHIP), and issuers of qualified health plans (QHPs). <br/>
Throughout this proposed rule, we refer to terms such as patient, consumer, beneficiary, <br/>
enrollee, and individual. We note that every reader of this proposed rule is a patient and has or <br/>
will receive medical care at some point in their life. In this proposed rule, we use the term <br/>
“patient” as an inclusive term, but because we have historically referred to patients using other <br/>
terms in our regulations, we use specific terms as applicable in sections of this proposed rule to <br/>
<hr/>
<a name=5></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>5</b> <br/>
refer to individuals covered under the health care programs that CMS administers and regulates. <br/>
We also use terms such as payer, plan, and issuer in this proposed rule. Certain portions of this <br/>
proposed rule are applicable to the Medicare Fee-for-Service (FFS) Program, the Medicaid FFS <br/>
Program, the CHIP FFS program, Medicare Advantage (MA) Organizations, Medicaid Managed <br/>
Care plans (managed care organizations (MCOs), prepaid inpatient health plans (PIHPs) and <br/>
prepaid ambulatory health plans (PAHPs)), CHIP Managed Care entities (MCOs, PIHPs, and <br/>
PAHPs), and QHP issuers in Federally-facilitated Exchanges (FFEs). We use the term “payer” as <br/>
an inclusive term, but we use specific terms as applicable in sections of this proposed rule. <br/>
B. Overview <br/>
We are dedicated to enhancing and protecting the health and well-being of all<b> </b>Americans. <br/>
One critical issue in the U.S. health care system is that people cannot easily access their complete <br/>
health information in interoperable forms. Patients and the health care providers caring for them <br/>
are often presented with an incomplete picture of their health and care as pieces of their <br/>
information are stored in various, unconnected systems and do not accompany the patient to <br/>
every care setting. <br/>
<br/>
We believe patients should have the ability to move from health plan to health plan, <br/>
provider to provider, and have both their clinical and administrative information travel with them <br/>
throughout their journey. When a patient receives care from a new provider, a complete record of <br/>
their health information should be readily available to that care provider, regardless of where or <br/>
by who care was previously provided. When a patient is discharged from a hospital to a post-<br/>
acute care (PAC) setting there should be no question as to how, when, or where their data will be <br/>
exchanged. Likewise, when an enrollee changes health plans or ages into Medicare, the enrollee <br/>
should be able to have their claims history and encounter data follow so that information is not <br/>
lost.<b> </b><br/>
<hr/>
<a name=6></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>6</b> <br/>
<br/>
For providers in clinical settings, health information technology (health IT) should be a <br/>
resource, designed to make it faster and easier for providers to deliver high quality care, creating <br/>
efficiencies and allowing them to access all available data for their patients. Health IT should not <br/>
detract from the clinician-patient relationship, from the patient’s experience of care, or from the <br/>
quality of work life for physicians, nurses, and other health care professionals. Through <br/>
standards-based interoperability and exchange, health IT has the potential to be a resource and <br/>
facilitator for efficient, safe, high-quality care for individuals and populations. <br/>
<br/>
All payers, including health plans, should have the ability to exchange data seamlessly <br/>
with other payers for timely benefits coordination or transitions, and with providers to facilitate <br/>
more coordinated and efficient care. Health plans are in a unique position to provide enrollees a <br/>
complete picture of their claims and encounter data, allowing patients to piece together their own <br/>
information that might otherwise be lost in disparate systems. This information can contribute to <br/>
better informed decision making, helping to inform the patient’s choice of coverage options and <br/>
care providers to more effectively manage their own health, care, and costs. <br/>
<br/>
We are committed to solving the issue of interoperability and patient access in the U.S. <br/>
health care system while reducing administrative burdens on providers and are taking an active <br/>
approach using all available policy levers and authorities to move participants in the health care <br/>
market toward interoperability and the secure and timely exchange of health care information. <br/>
C. Executive Order and MyHealthEData <br/>
<br/>
<br/>
On October 12, 2017, President Trump issued Executive Order 13813 to Promote <br/>
Healthcare Choice and Competition Across the United States. Section 1(c)(iii) of Executive <br/>
Order 13813 states that the Administration will improve access to, and the quality of, <br/>
information that Americans need to make informed health care decisions, including information <br/>
<hr/>
<a name=7></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>7</b> <br/>
about health care prices and outcomes, while minimizing reporting burdens on affected plans, <br/>
providers, and payers.<b> </b><br/>
<br/>
In support of Executive Order 13813, the Administration launched the MyHealthEData <br/>
initiative. This government-wide initiative aims to empower patients by ensuring that they have <br/>
full access to their own health information and the ability to decide how their data will be used, <br/>
while keeping that information safe and secure. MyHealthEData aims to break down the barriers <br/>
that prevent patients from gaining electronic access to their health information from the device or <br/>
application of their choice, empowering patients and taking a critical step toward interoperability <br/>
and patient data exchange.<b> </b><br/>
<br/>
In March 2018, the White House Office of American Innovation and the CMS <br/>
Administrator announced the launch of MyHealthEData, and CMS’s direct, hands-on role in <br/>
improving patient access and advancing interoperability. As part of the MyHealthEData <br/>
initiative, we are taking a patient-centered approach to health information access and moving to a <br/>
system in which patients have immediate access to their computable health information and can <br/>
be assured that their health information will follow them as they move throughout the health care <br/>
system from provider to provider, payer to payer. To accomplish this, we have launched several <br/>
initiatives related to data sharing and interoperability to empower patients and encourage plan <br/>
and provider competition. In this proposed rule, we continue to advance the policies and goals of <br/>
the MyHealthEData initiative through various proposals as outlined in the following sections.<b> </b><br/>
<br/>
Our proposals are wide-reaching and would have an impact on all facets of the health <br/>
care system. Several key touch points of the proposals in this rule include: <br/>
<b>● </b><i>Patients</i>: Enabling patients to access their health information electronically without <br/>
special effort by requiring the payers subject to this proposed rule to make the data available <br/>
through an application programming interface (API) to which third party software applications <br/>
<hr/>
<a name=8></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>8</b> <br/>
connect to make the data available to patients. This encourages them to take charge of and better <br/>
manage their health care, and thus these initiatives are imperative to improving a patient’s long-<br/>
term health outcomes. <br/>
● <i>Clinicians and Hospitals</i>: Ensuring that health care providers have ready access to <br/>
health information about their patients, regardless of where the patient may have previously <br/>
received care. We are also proposing policies to prevent health care providers from <br/>
inappropriately restricting the flow of information to other health care providers and payers.<b> </b><br/>
Finally, we are working to ensure that better interoperability reduces the burden on health care <br/>
providers.<b> </b><br/>
● <i>Payers</i>: Proposing requirements to ensure that payers (that is, entities and <br/>
organizations that pay for health care), such as MA plans and Medicaid and CHIP programs, <br/>
make enrollee electronic health information held by the plan available through an API such that, <br/>
with use of software we expect payers and third parties to develop, the information becomes <br/>
easily accessible to the enrollee, and that the data flows seamlessly with the enrollee as they <br/>
change providers, plans, and issuers. Additionally, our proposals would ensure that payers make <br/>
it easy for current and prospective enrollees to identify which providers are within a given plan’s <br/>
network in a way that is simple and easy for enrollees to access and understand, and thus find the <br/>
providers that are right for them. <b> </b><br/>
<br/>
Under our proposals to standardize data and technical approaches to advance <br/>
interoperability, we believe health care providers and their patients, as well as other key <br/>
participants within the health care ecosystem such as plans and payers, will have appropriate <br/>
access to the information necessary to coordinate individual care, analyze population health <br/>
trends, outcomes, and costs, and manage benefits and the health of populations, while tracking <br/>
progress through quality improvement initiatives.<b> </b>We are working with other federal partners <br/>
<hr/>
<a name=9></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>9</b> <br/>
including the Office of the National Coordinator for Health Information Technology (ONC) on <br/>
this effort with the clear objective to improve patient access and care, alleviate provider burden, <br/>
and reduce overall health care costs.<b> </b><br/>
D. Past Efforts<b> </b><br/>
<br/>
The Department of Health and Human Services (HHS) has been working to advance the <br/>
interoperability of electronic health information since 2004, when the ONC was initially created <br/>
via Executive Order 13335. From 2004 to 2009, ONC worked with a variety of federal and <br/>
private sector stakeholders to coordinate private and public actions, began harmonizing data <br/>
standards, and worked to advance nationwide health information exchange. In 2009, the National <br/>
Coordinator position, office, and statutory duties were codified by the Health Information <br/>
Technology for Economic and Clinical Health Act (HITECH Act), enacted as part of the <br/>
American Recovery and Reinvestment Act of 2009 (Pub. L. 111-5, enacted February 17, 2009), <br/>
at Title 42—Health Information Technology and Quality (42 U.S.C. 300jj <i>et seq.</i>) of the Public <br/>
Health Service Act (PHSA). Under section 3001(c)(5) of the PHSA, ONC established a <br/>
voluntary certification program to certify that health IT met standards, implementation <br/>
specifications, and certification criteria adopted by the Secretary. ONC is organizationally <br/>
located within HHS’ Office of the Secretary and is the principal federal entity charged with <br/>
coordination of nationwide efforts to implement and use the most advanced health IT and the <br/>
electronic exchange of health information.<b> </b><br/>
<br/>
The HITECH Act provided the opportunity to move interoperability forward in many <br/>
additional meaningful ways. A few are particularly worth noting in relation to this proposed rule. <br/>
For instance, HITECH also amended the Social Security Act (the Act), authorizing CMS to make <br/>
incentive payments (and in later years, make downward adjustments to Medicare payments) to <br/>
eligible professionals, eligible hospitals and critical access hospitals (CAHs), and MA <br/>
<hr/>
<a name=10></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>10</b> <br/>
organizations to promote the adoption and meaningful use of certified electronic health record <br/>
technology (CEHRT). In 2010, through rulemaking, we established criteria for the Medicare and <br/>
Medicaid Electronic Health Record (EHR) Incentive Programs to encourage eligible <br/>
professionals, eligible hospitals, and CAHs to adopt, implement, upgrade, and demonstrate the <br/>
meaningful use of CEHRT. The programs were implemented in three stages: <br/>
● Stage 1 set the foundation for the EHR Incentive Programs by establishing <br/>
requirements for the electronic capture of clinical data, including providing patients with <br/>
electronic copies of health information. <br/>
● Stage 2 expanded upon the Stage 1 criteria with a focus on advancing clinical <br/>
processes and ensuring that the meaningful use of EHRs supported the aims and priorities of the <br/>
National Quality Strategy. Stage 2 criteria encouraged the use of CEHRT for continuous quality <br/>
improvement at the point of care and the exchange of information in the most structured format <br/>
possible. <br/>
● Stage 3 focuses on using CEHRT to improve health outcomes.<b> </b><br/>
<br/>
The federal government has spent over $35 billion under the EHR Incentive Programs to <br/>
incentivize the adoption and meaningful use of EHR systems by eligible professionals, eligible <br/>
hospitals, and CAHs; however, despite the fact that 78 percent of physicians<a href="CMSs.html#10">1</a> and 96 percent of <br/>
hospitals<a href="CMSs.html#10">2 </a>now use a certified EHR system, progress on system-wide data sharing has been <br/>
limited. <br/>
<br/>
In 2010, under the HITECH Act, ONC adopted an initial set of standards, implementation <br/>
specifications, and certification criteria, and established the Temporary Certification Program for <br/>
<br/>
1 ONC, <i>Health IT Dashboard</i>, “Office-based Physician Health IT Adoption: State rates of physician EHR adoption, <br/>health information exchange & interoperability, and patient engagement (2015),” <br/><a href="https://dashboard.healthit.gov/apps/physician-health-it-adoption.php">https://dashboard.healthit.gov/apps/physician-health-it-adoption.php </a>(last accessed July 9, 2018). <br/>2 ONC, <i>Health IT Dashboard</i>, “Non-federal Acute Care Hospital Health IT Adoption and Use: State rates of non-<br/>federal acute care hospital EHR adoption, health information exchange and interoperability, and patient engagement <br/>(2015),”<a href="https://dashboard.healthit.gov/apps/hospital-health-it-adoption.php"> https://dashboard.healthit.gov/apps/hospital-health-it-adoption.php </a>(last accessed July 9, 2018). <br/>
<hr/>
<a name=11></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>11</b> <br/>
Health Information Technology, under which health IT developers could begin to obtain <br/>
certification of the EHR technology that eligible professionals, eligible hospitals, and CAHs <br/>
would need to adopt and use to satisfy CMS Stage 1 requirements for demonstration of <br/>
meaningful use of CEHRT. In January 2011, ONC replaced the Temporary Certification <br/>
Program with the Permanent Certification Program for Health Information Technology (45 CFR <br/>
part 170). The Secretary has adopted iterative editions of the set of standards, implementation <br/>
specifications, and certification criteria included in the Programs to keep pace with advances in <br/>
standards, health information exchange, and the health IT market. In addition, this helps to <br/>
maintain alignment with the needs of health care providers seeking to succeed within health IT-<br/>
linked federal programs. <br/>
<b> </b><br/>
In April 2015, Congress passed the Medicare Access and CHIP Reauthorization Act of <br/>
2015 (MACRA) (Pub. L. 114-10, enacted April 16, 2015), which declared it a national objective <br/>
to achieve widespread exchange of health information through interoperable CEHRT <br/>
nationwide. Section 106(b)(1)(B)(ii) of MACRA defines “interoperability” as the ability of two <br/>
or more health information systems or components to exchange clinical and other information <br/>
and to use the information that has been exchanged using common standards as to provide access <br/>
to longitudinal information for health care providers in order to facilitate coordinated care and <br/>
improved patient outcomes. The MACRA charges the Secretary to establish metrics to be used to <br/>
determine if widespread interoperability had been achieved, and the heading of section 106(b)(2) <br/>
of the MACRA refers to “preventing blocking the sharing of information.” Specifically, section <br/>
106(b)(2) of the MACRA amended section 1848(o)(2)(A)(ii) of the Act for eligible professionals <br/>
and section 1886(n)(3)(A)(ii) of the Act for eligible hospitals and CAHs to require that the <br/>
professional or hospital demonstrate that they have not knowingly and willfully taken action to <br/>
limit or restrict the compatibility or interoperability of CEHRT. For a discussion of the <br/>
<hr/>
<a name=12></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>12</b> <br/>
attestation requirements that we established and codified to support the prevention of information <br/>
blocking, we refer readers to the CY 2017 Quality Payment Program final rule (81 FR 77028 <br/>
through 77035). <br/>
<br/>
In April 2018, we renamed the EHR Incentive Programs and the MIPS Advancing Care <br/>
Information performance category to the Promoting Interoperability (PI) Programs and <br/>
Promoting Interoperability performance category, respectively (83 FR 41635). This refocusing <br/>
and rebranding of the initiatives is just one part of the CMS strategic shift in focus to advancing <br/>
health IT and interoperability. <b> </b><br/>
CMS appreciates the pathways Congress opened for action on interoperability, as will be <br/>
discussed in more detail throughout this proposed rule and has been working diligently with <br/>
ONC to support implementation. In addition, in order to make sure we have as much stakeholder <br/>
feedback on all the options CMS specifically has available to best take advantage of this new <br/>
opportunity to promote interoperability, over a span of several months in 2018, we released <br/>
interoperability Requests for Information (RFIs) in several Medicare payment rules, including in <br/>
the FY 2019 Inpatient Prospective Payment System (IPPS) proposed rule (83 FR 20164). While <br/>
the Interoperability RFI in the FY 2019 IPPS proposed rule was focused primarily on how and <br/>
whether changes to Hospital Conditions of Participation and other like program requirements <br/>
could impact or contribute to advancing interoperability, stakeholders provided additional input <br/>
that we are taking under advisement for the purposes of advancing interoperability generally in <br/>
this proposed rule. For example, some commenters recommended aligning existing standards <br/>
and adopting common standards and/or data elements across the health care industry as a whole <br/>
(not just focusing on providers), incentivizing the use of standards, and removing barriers as <br/>
possible ways to address gaps in interoperability. Commenters also expressed support for the use <br/>
of open APIs but cautioned CMS to consider the need to ensure health information security. <br/>
<hr/>
<a name=13></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>13</b> <br/>
Support was also expressed for enhancing applications that are designed for patient, or consumer <br/>
use, such as Blue Button 2.0 (CMS’ Medicare FFS open API for patient access to health <br/>
information), and the development of patient-facing consumer applications that aggregate <br/>
various longitudinal health information for the patient into one location. We plan to continue to <br/>
review the public comments we receive to help identify opportunities for CMS to advance <br/>
interoperability in future rulemaking and subregulatory guidance. <br/>
CMS is also working with partners in the private sector to promote interoperability. In <br/>
2018, CMS began participating in the Da Vinci project, a private-sector initiative led by Health <br/>
Level 7 (HL7), a standards development organization. For one of the use cases under this project <br/>
– called “Coverage Requirements and Documentation Rules Discovery” – the Da Vinci project <br/>
developed a draft Fast Healthcare Interoperability Resources (FHIR) standard during the summer <br/>
and fall of 2018. In June 2018, in support of the Da Vinci project, the CMS Medicare FFS <br/>
program began: (1) developing a prototype Documentation Requirement Lookup Service for the <br/>
Medicare FFS program; (2) populating it with the list of items/services for which prior <br/>
authorization is required by the Medicare FFS program; and (3) populating it with the <br/>
documentation rules for oxygen and Continuous Positive Airway Pressure (CPAP) devices. <br/>
More information about the FFS Medicare program’s efforts to support these Da Vinci use cases <br/>
are available at<a href="http://go.cms.gov/MedicareRequirementsLookup"> go.cms.gov/MedicareRequirementsLookup. </a> <br/>
We encourage all payers, including but not limited to MA organizations, Medicaid <br/>
managed care plans and CHIP managed care entities, and QHP issuers in FFEs to follow CMS’s <br/>
example and align with the Da Vinci Project to: (1) develop a similar lookup service; (2) <br/>
populate it with their list of items/services for which prior authorization is required; and (3) <br/>
populate it with the documentation rules for at least oxygen and CPAP. By taking this step, <br/>
health plans can join CMS in helping to build an ecosystem that will allow providers to connect <br/>
<hr/>
<a name=14></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>14</b> <br/>
their EHRs or practice management systems and efficient work flows with up-to-date <br/>
information on which items and services require prior authorization and what the documentation <br/>
requirements are for various items and services under that patient’s current plan enrollment. <br/>
In the 8 years since the first HHS rulemakings to implement HITECH, significant <br/>
progress has been made in the adoption of EHRs by hospitals and clinicians; however, progress <br/>
on interoperability needs to be accelerated. <br/>
In section 106(b) of MACRA, Congress declared it a national objective to achieve <br/>
widespread exchange of health information through interoperable certified EHR technology <br/>
nationwide by December 31, 2018. Not later than July 1, 2016, the Secretary was to establish <br/>
metrics to be used to determine if and to the extent this objective was achieved. If the objective is <br/>
not achieved by December 31, 2018, the Secretary must submit a report not later than December <br/>
31, 2019, that identifies barriers to the objective and recommends actions that the federal <br/>
government can take to achieve the objective. In April 2016, ONC published the “Office of the <br/>
National Coordinator for Health Information Technology; Medicare Access and CHIP <br/>
Reauthorization Act of 2015; Request for Information Regarding Assessing Interoperability for <br/>
MACRA” RFI (81 FR 20651). Based on stakeholder input received in response to the RFI, ONC <br/>
subsequently identified the following two metrics for interoperability (see <br/>
<a href="https://www.healthit.gov/sites/default/files/fulfilling_section_106b1c_of_the_medicare_access_and_chip_reauthorization_act_of_2015_06.30.16.pdf">https://www.healthit.gov/sites/default/files/fulfilling_section_106b1c_of_the_medicare_access_a</a><br/>
<a href="https://www.healthit.gov/sites/default/files/fulfilling_section_106b1c_of_the_medicare_access_and_chip_reauthorization_act_of_2015_06.30.16.pdf">nd_chip_reauthorization_act_of_2015_06.30.16.pdf):</a> <br/>
● Measure #1: Proportion of health care providers who are electronically engaging in the <br/>
following core domains of interoperable exchange of health information: sending, receiving, <br/>
finding (querying), and integrating information received from outside sources. <br/>
● Measure #2: Proportion of health care providers who report using the information they <br/>
electronically receive from outside providers and sources for clinical decision-making. <br/>
<hr/>
<a name=15></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>15</b> <br/>
ONC recently provided an update on these metrics in its 2018 Report to Congress - <br/>
Annual Update on the Adoption of a Nationwide System for the Electronic Use and Exchange of <br/>
Health Information (s<a href="https://www.healthit.gov/sites/default/files/page/2018-12/2018-HITECH-report-to-congress.pdf">ee https://www.healthit.gov/sites/default/files/page/2018-12/2018-</a><br/>
<a href="https://www.healthit.gov/sites/default/files/page/2018-12/2018-HITECH-report-to-congress.pdf">HITECH-report-to-congress.pdf)</a>. ONC will continue to evaluate nationwide performance <br/>
according to the identified metrics, and believes current developments, such as policy changes <br/>
being implemented under the 21st Century Cures Act (Cures Act) (Pub. L. 114-255, enacted <br/>
December 13, 2016) will contribute to increasingly improved performance under these metrics. <br/>
In addition, the Cures Act included provisions to advance interoperability and health <br/>
information exchange, including, for example, enhancements to ONC’s Health IT certification <br/>
program and a definition of “information blocking” (as discussed further in section VIII. of this <br/>
proposed rule). These provisions have been addressed in depth in ONC’s proposed rule “21st <br/>
Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification <br/>
Program” (published elsewhere in this <b>Federal Register</b>). <br/>
Section 4003 of the Cures Act added a definition of “interoperability” as paragraph 10 of <br/>
section 3000 of the PHSA (42 U.S.C. 300jj (9)) (as amended). Under section 3000 of the PHSA, <br/>
‘interoperability’, with respect to health IT, means technology that enables the secure exchange <br/>
of electronic health information with, and use of electronic health information from, other health <br/>
IT without special effort on the part of the user. It also allows for complete access, exchange, <br/>
and use of all electronically accessible health information for authorized use under applicable <br/>
state or federal law and does not constitute information blocking as defined in section 3022(a) of <br/>
the PHSA.<b> </b><br/>
<br/>
This definition aligns with the definition under MACRA and the HHS vision and strategy <br/>
for achieving a health information ecosystem within which all individuals and their health care <br/>
providers are able to send, receive, find, and use electronic health information in a manner that is <br/>
<hr/>
<a name=16></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>16</b> <br/>
appropriate, secure, timely, and reliable to support the health and wellness of individuals through <br/>
informed shared decision-making, as well as through patient choice of health plans and <br/>
providers. Accordingly, except where we further or otherwise specify for a specific policy or <br/>
purpose, when we use the term “interoperability” within this proposed rule we are referring to <br/>
the definition in section 3000 of the PHSA.<b> </b><br/>
E. Challenges and Barriers to Interoperability <br/>
Through significant stakeholder feedback, we understand that there are many barriers to <br/>
interoperability which have obstructed progress over the years. We have conducted stakeholder <br/>
meetings and roundtables; solicited comments via RFIs; and received additional feedback <br/>
through letters and rulemaking. All of this input together has contributed to our proposals in this <br/>
proposed rule. Some of the main barriers shared with us are addressed in the following sections. <br/>
While we have made efforts to address some of these barriers in this proposed rule and through <br/>
prior rules and actions, we believe there is still considerable work to be done to overcome some <br/>
of these considerable challenges toward achieving interoperability. <br/>
1. Patient Identifier and Interoperability <br/>
In the Interoperability RFI in the FY 2019 IPPS proposed rule (83 FR 20550), we <br/>
solicited feedback on positive solutions to better achieve interoperability or the sharing of health <br/>
care information between providers. A number of commenters noted that the lack of a unique <br/>
patient identifier (UPI) inhibited interoperability efforts because, without a unique identifier for <br/>
each patient, the safe and secure electronic exchange of health information is constrained <br/>
because it is difficult to ensure that the relevant records are all for the same patient. <br/>
As part of efforts to reduce the administrative costs of providing and paying for health <br/>
care, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) (Pub. L. 104-<br/>
191, enacted August 21, 1996) required the adoption of a “unique individual identifier for <br/>
<hr/>
<a name=17></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>17</b> <br/>
healthcare purposes,” commonly referred to as a UPI. At the time HIPAA was enacted, HHS <br/>
began to consider what information would be needed to develop a rule to adopt a UPI standard. <br/>
An initial Notice of Intent to issue a proposed rule on requirements for a unique health identifier <br/>
for individuals was published in the November 2, 1998 <b>Federal Register</b> (63 FR 61773-61774). <br/>
Such an identifier has the potential to facilitate the accurate portability of health <br/>
information by allowing correct patient matching because the universal identifier allows for <br/>
accurate and timely patient record linking between providers across the care continuum and it <br/>
allows a patient’s complete record to easily move with them from provider to provider. However, <br/>
stakeholders immediately raised significant concerns regarding the impact of this UPI on health <br/>
information security and privacy. Stakeholders were concerned that if there was a single <br/>
identifier used across systems, it would be easier for that information to be compromised, <br/>
exposing protected health information (PHI) more easily than in the current medical record <br/>
environment that generally requires linking several pieces of personally identifying information <br/>
to link health records. <br/>
The National Committee on Vital Health Statistics (NCVHS), the statutory public <br/>
advisory body to the Secretary of Health and Human Services (the Secretary) for health data, <br/>
statistics, privacy, and national health information policy and HIPAA, conducted extensive <br/>
hearings in the first year after HIPAA was enacted to evaluate this and other HIPAA-related <br/>
implementation issues. The NCVHS First Annual Report to the Congress on the Implementation <br/>
of the Administrative Simplification Provisions of the Health Insurance Portability and <br/>
Accountability Act, February 3, 1998, outlines the NCVHS’ efforts to obtain feedback on the <br/>
UP<a href="https://ncvhs.hhs.gov/wp-content/uploads/2018/03/yr1-rpt-508.pdf">I (https://ncvhs.hhs.gov/wp-content/uploads/2018/03/yr1-rpt-508.pdf)</a>. Through this process, <br/>
NCVHS found a lack of consensus on how best to define a UPI and controversy around the use <br/>
of a UPI due to privacy and data security concerns. Those in favor of adopting a UPI believe a <br/>
<hr/>
<a name=18></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>18</b> <br/>
UPI is the most efficient way to foster information sharing and accurate patient record linking, <br/>
where those against it are concerned about patient privacy and data security. NCVHS found <br/>
these privacy and data security concerns outweighed the benefits of a UPI. <br/>
The NCVHS recommended that the Secretary not move forward with a proposed rule on <br/>
a patient identifier until further discussions could be had to fully understand the privacy and data <br/>
security concerns, as well as the full breadth of options beyond a single identifier. NCVHS <br/>
suggested the Secretary work to maximize public participation in soliciting a variety of options <br/>
for establishing an identifier or an alternative approach for identifying individuals and linking <br/>
health information of individuals for health purposes. <br/>
Appreciating the significant concerns raised by stakeholders regarding implementing a <br/>
UPI, Congress included language in the Omnibus Consolidated and Emergency Supplemental <br/>
Appropriations Act of 1999 (Pub. L. 105-277, enacted October 21, 1998) and in each subsequent <br/>
Appropriations bill, stating “None of the funds made available in this Act may be used to <br/>
promulgate or adopt any final standard under section 1173(b) of the Act (42 U.S.C. 1320d–2(b)) <br/>
providing for, or providing for the assignment of, a unique health identifier for an individual <br/>
(except in an individual’s capacity as an employer or a health care provider), until legislation is <br/>
enacted specifically approving the standard.” This language has effectively prohibited HHS from <br/>
engaging in rulemaking to adopt a UPI standard. Consequently, the Secretary withdrew the <br/>
Notice of Intent to pursue rulemaking on this issue on August 9, 2000 <br/>
<a href="https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=200010&RIN=0938-AI91">(https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=200010&RIN=0938-AI91).</a> <br/>
In recent years, concerns regarding the privacy and security of information have only <br/>
increased. For example, in the first quarter through third quarter of FY 2018 (October 1, 2017 <br/>
through June 30, 2018), 276 breach incidents were reported to the HHS Office of Civil Rights <br/>
(OCR) affecting 4,341,595 individuals <a href="https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf">(https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf)</a>. <br/>
<hr/>
<a name=19></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>19</b> <br/>
Although the appropriations language regarding the UPI standard has remained <br/>
unchanged, in the report accompanying the 2017 appropriations bill, Congress additionally <br/>
stated, “Although the Committee continues to carry a prohibition against HHS using funds to <br/>
promulgate or adopt any final standard providing for the assignment of a unique health identifier <br/>
for an individual until such activity is authorized, the Committee notes that this limitation does <br/>
not prohibit HHS from examining the issues around patient matching. Accordingly, the <br/>
Committee encouraged the Secretary, acting through ONC and CMS, to provide technical <br/>
assistance to private-sector led initiatives to develop a coordinated national strategy that will <br/>
promote patient safety by accurately identifying patients to their health information.” (H.R. Rep. <br/>
No. 114–<a href="https://www.gpo.gov/fdsys/pkg/CRPT-114hrpt699/pdf/CRPT-114hrpt699.pdf">699, p. 110, https://www.gpo.gov/fdsys/pkg/CRPT-114hrpt699/pdf/CRPT-</a><br/>
<a href="https://www.gpo.gov/fdsys/pkg/CRPT-114hrpt699/pdf/CRPT-114hrpt699.pdf">114hrpt699.pdf)</a>. Congress has repeated this guidance for 2018 and 2019. This guidance directed <br/>
HHS to focus on examining issues around patient matching and to provide technical assistance to <br/>
private sector-led initiatives focusing on a patient matching solution. <br/>
Unlike a UPI, which assigns a unique identifier – either numerical or otherwise – to each <br/>
patient, patient matching is a process by which health information from multiple sources is <br/>
compared to identify common elements, with the goal of identifying records representing a <br/>
single patient. This is generally done by using multiple demographic data fields such as name, <br/>
birth date, gender, and address. The goal of patient matching is to link one patient’s data across <br/>
multiple databases within and across health care providers in order to obtain a comprehensive <br/>
view of that patient’s health care information. <br/>
ONC has stated that patient matching is critically important to interoperability and the <br/>
nation’s health IT infrastructure as health care providers must be able to share patient health <br/>
information and accurately match a patient to his or her data from a different provider in order <br/>
for many anticipated interoperability benefits to be realized. <br/>
<hr/>
<a name=20></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>20</b> <br/>
Patient matching can be less precise than a UPI due to the reliance on demographic <br/>
attributes (such as name and date of birth) which are not unique traits to a particular patient; <br/>
further, patient matching is often dependent on manual data entry and data maintained in varying <br/>
formats. Matching mistakes can contribute to adverse events, compromised safety and privacy, <br/>
and increased health care costs (s<a href="https://www.healthit.gov/sites/default/files/hie-interoperability/nationwide-interoperability-roadmap-final-version-1.0.pdf">ee https://www.healthit.gov/sites/default/files/hie-</a><br/>
<a href="https://www.healthit.gov/sites/default/files/hie-interoperability/nationwide-interoperability-roadmap-final-version-1.0.pdf">interoperability/nationwide-interoperability-roadmap-final-version-1.0.pdf)</a>. However, a wide <br/>
range of strategies and best practices currently being deployed across the industry have been <br/>
shown to improve patient matching rates, suggesting that patient matching approaches can be an <br/>
effective solution when appropriately implemented (see <br/>
<a href="https://www.healthit.gov/sites/default/files/patient_identification_matching_final_report.pdf">https://www.healthit.gov/sites/default/files/patient_identification_matching_final_report.pdf).</a> <br/>
Many stakeholders commenting on the interoperability RFIs included in the 2019 <br/>
proposed payment rules indicated that patient matching is a “core functionality” of patient <br/>
identification and necessary to ensure care coordination and the best patient outcomes. <br/>
Commenters also noted that a consistently used matching strategy could accomplish the original <br/>
goals of a UPI with a diminished risk to individual privacy and health information security. <br/>
Several commenters noted that the lack of a UPI impacted interoperability, but finding a <br/>
suitable and consistent matching strategy could address this issue. These commenters often <br/>
specifically supported Congress’ guidance to have ONC and CMS provide technical assistance to <br/>
the private sector to identify this strategy. To help jump start the process of finding a solution to <br/>
patient matching, ONC launched the Patient Matching Algorithm Challenge in 2017, awarding <br/>
six winners $75,000 in grants in late 2017 <br/>
<a href="https://www.patientmatchingchallenge.com/challenge-information/challenge-details">(https://www.patientmatchingchallenge.com/challenge-information/challenge-details)</a>. The goal <br/>
of the Patient Matching Algorithm Challenge was to bring about greater transparency and data <br/>
on the performance of existing patient matching algorithms, spur the adoption of performance <br/>
<hr/>
<a name=21></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>21</b> <br/>
metrics for patient data matching algorithm vendors, and positively impact other aspects of <br/>
patient matching such as deduplication and linking to clinical data. <br/>
We continue to support ONC’s work promoting the development of patient matching <br/>
initiatives. Per Congress’ guidance, ONC is looking at innovative ways to provide technical <br/>
assistance to private sector-led initiatives to further develop accurate patient matching solutions <br/>
in order to promote interoperability without requiring a UPI. <br/>
We understand the significant health information privacy and security concerns raised <br/>
around the development of a UPI standard and the current prohibition against using HHS funds <br/>
to adopt a UPI standard. Recognizing Congress’ statement regarding patient matching and <br/>
stakeholder comments stating that a patient matching solution would accomplish the goals of a <br/>
UPI, we seek comment for future consideration on ways for ONC and CMS to continue to <br/>
facilitate private sector efforts on a workable and scalable patient matching strategy so that the <br/>
lack of a specific UPI does not impede the free flow of information. We also seek comment on <br/>
how we may leverage our program authority to provide support to those working to improve <br/>
patient matching. In addition, we intend to use comments for the development of policy and <br/>
future rulemaking. <br/>
2. Lack of standardization <br/>
<br/>
Lack of standardization inhibits the successful exchange of health information without <br/>
additional effort on the part of the end user. To achieve secure exchange of health information <br/>
across health IT products and systems that can be readily used without special effort by the user, <br/>
both the interface technology and the underlying data must be standardized, so all systems are <br/>
“speaking the same language.” Consistent use of modern computing standards and applicable <br/>
content standards (such as clinical vocabularies) are fundamental to achieving full-scale <br/>
technical interoperability (systems can connect and exchange data unaltered) and semantic <br/>
<hr/>
<a name=22></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>22</b> <br/>
interoperability (systems can interpret and use the information that has been exchanged). Lack of <br/>
such standards creates a barrier to interoperability. Where specific standards are not consistently <br/>
used, particularly to structure exchange interfaces such as APIs, the exchange is more difficult <br/>
and expensive than it needs to be and the recipient of exchanged data must often undertake <br/>
substantial special effort to make sense of the information. <br/>
In this proposed rule, similar to CMS’ Blue Button 2.0 approach for Medicare FFS<a href="CMSs.html#22">3</a>, we <br/>
propose to require that all MA organizations, Medicaid managed care plans, CHIP managed care <br/>
entities, Medicaid state agencies, CHIP agencies that operate FFS systems, and issuers of QHPs <br/>
in the FFEs, deploy standardized, open APIs to make certain information available to enrollees <br/>
as discussed in section III. of this proposed rule. <br/>
The lack of a sufficiently mature API functionality technical standard has posed a <br/>
challenge and impediment to advancing interoperability. In 2015, ONC finalized an API <br/>
functionality certification criterion in the “2015 Edition Health Information Technology (Health <br/>
IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and <br/>
ONC Health IT Certification Program Modifications” Final Rule (2015 Edition final rule) (80 <br/>
FR 62602). However, while a consensus technical standard specific to the API technical <br/>
functionality was in development, it had not yet matured enough for inclusion in the 2015 <br/>
Edition final rule, which does not identify a specific standard for API functionality. <br/>
As discussed in greater detail in section II of this proposed rule, we believe that a specific <br/>
foundational standard for API functionality has matured sufficiently enough for ONC to propose <br/>
it for HHS adoption (published elsewhere in this <b>Federal Register</b>). To take full advantage of <br/>
this proposed standard, as well as already adopted standards applicable to content exchanged via <br/>
APIs, we propose in sections II. and III. of this proposed rule to require that MA organizations, <br/>
<br/>
3 We refer readers t<a href="https://bluebutton.cms.gov/">o https://bluebutton.cms.gov </a>for more information related to the CMS Blue Button initiative. <br/>
<hr/>
<a name=23></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>23</b> <br/>
Medicaid managed care plans, Medicaid state agencies, CHIP managed care entities, CHIP <br/>
agencies that operate FFS systems, and QHP issuers in FFEs deploy API technologies <br/>
conformant with the API technical standard proposed by ONC for HHS adoption at 45 CFR <br/>
170.215 and other applicable standards such as content and vocabulary standards adopted at 45 <br/>
CFR part 162 and 42 CFR 423.160, and proposed by ONC for HHS adoption at 45 CFR 170.213 <br/>
(published elsewhere in this <b>Federal Register</b>). Furthermore, we note that we intend to continue <br/>
to work with stakeholders to develop standards that will advance interoperability. <br/>
3. Information Blocking <br/>
As explained above, information blocking is defined in section 3022(a) of the PHSA. <br/>
Understanding this definition, information blocking could be considered to include the practice <br/>
of withholding data, or intentionally taking action to limit or restrict the compatibility or <br/>
interoperability of health IT. Through stakeholder outreach, roundtables, and letters we have <br/>
received, we understand that health care providers may limit or prevent data exchange in an <br/>
effort to retain patients. By withholding a patient’s health information from competing health <br/>
care providers, a health care provider can effectively inhibit a patient from freely moving within <br/>
the health care market because that patient would not otherwise have access to their complete <br/>
health information. <br/>
We additionally understand from stakeholder feedback that in certain cases a health IT <br/>
vendor has prohibited the movement of data from one health IT system to another in an effort to <br/>
maintain their customer base. <br/>
Information blocking is a significant threat to interoperability and can limit the ability for <br/>
providers to coordinate care and treat a patient based on the most comprehensive information <br/>
available. In sections VIII.B. and C. of this proposed rule we propose to publicly report the <br/>
names of clinicians and hospitals who submit a “no” response to certain attestation statements <br/>
<hr/>
<a name=24></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>24</b> <br/>
related to the prevention of information blocking in order to deter health care providers from <br/>
engaging in conduct that could be considered information blocking. <br/>
Preventing and avoiding information blocking is important to advancing interoperability. <br/>
We believe this proposal would help discourage health care providers from information blocking <br/>
and clearly indicates CMS’s commitment to preventing such practices. <br/>
4. Lack of adoption/use of certified health IT among post-acute care (PAC) providers <br/>
PAC facilities are critical in the care of patients’ post-hospital discharge, and can be a <br/>
determining step in the health progress for those patients.<a href="CMSs.html#24">4</a> Interoperable health IT can improve <br/>
the ability of these facilities to coordinate and provide care; however, long-term care and PAC <br/>
providers, such as nursing homes, home health agencies (HHAs), long-term care providers, and <br/>
others, were not eligible for the EHR Incentive Programs under the HITECH Act. Based on the <br/>
information we have, we understand that this was a contributing factor to these providers not <br/>
adopting CEHRT at the same rate as eligible hospitals and physicians, who were able to adopt <br/>
CEHRT using the financial incentives provided under the programs.<a href="CMSs.html#24">5</a>,<a href="CMSs.html#24">6</a> <br/>
While a majority of skilled nursing facilities (SNFs) used an EHR in 2016 (64 percent), <br/>
there is considerable work to be done to increase adoption and the exchange of data in this <br/>
provider population. In that same year, only three out of 10 SNFs electronically exchanged (that <br/>
is, sent or received) key clinical health information, and only 7 percent had the ability to <br/>
electronically send, receive, find, and integrate patient health information. In 2017, an ONC <br/>
survey found that more HHA) (78 percent) adopted EHRs than SNFs (66 percent), but <br/>
integration of received information continued to lag behind for both HHAs (36 percent) and <br/>
<br/>
<a href="https://www.healthit.gov/sites/default/files/electronic-health-record-adoption-and-interoperability-among-u.s.-skilled-nursing-facilities-in-2016.pdf">4 https://www.healthit.gov/sites/default/files/electronic-health-record-adoption-and-interoperability-among-u.s.-<br/>skilled-nursing-facilities-in-2016.pdf. </a> <br/>5<a href="https://aspe.hhs.gov/report/opportunities-engaging-long-term-and-post-acute-care-providers-health-information-exchange-activities-exchanging-interoperable-patient-assessment-information/hit-and-ehr-certification-ltpac"> https://aspe.hhs.gov/report/opportunities-engaging-long-term-and-post-acute-care-providers-health-information-<br/>exchange-activities-exchanging-interoperable-patient-assessment-information/hit-and-ehr-certification-ltpac. </a> <br/><a href="https://www.healthit.gov/sites/default/files/pdf/HIT_LTPAC_IssueBrief031513.pdf">6 https://www.healthit.gov/sites/default/files/pdf/HIT_LTPAC_IssueBrief031513.pdf. </a> <br/>
<br/>
<hr/>
<a name=25></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>25</b> <br/>
SNFs (18 percent). While both ONC surveys focused on SNFs, it is important to note the large <br/>
provider overlap between SNFs and other nursing facilities. In 2014, 14,409 out of 15,640 (92 <br/>
percent) of nursing homes were certified for both Medicare and Medicaid.<a href="CMSs.html#25">7</a> <br/>
Long-term hospitals, inpatient rehabilitation facilities (IRFs), SNFs, and HHAs are <br/>
required to submit to CMS standardized patient assessment data described in section <br/>
1899B(b)(1) of the Act (as added by section 2(a) of the Improving Medicare Post-Acute Care <br/>
Transformation Act of 2014 (IMPACT Act) (Pub. L. 113-185, enacted October 6, 2014)). We <br/>
have defined the term “standardized patient assessment data” (or “standardized resident <br/>
assessment data” for purposes of SNFs) as patient or resident assessment questions and response <br/>
options that are identical in all four PAC assessment instruments, and to which identical <br/>
standards and definitions apply. Section 1899B(b)(1)(B) of the Act states that the categories for <br/>
which standardized patient or resident assessment data must be submitted include, at a minimum, <br/>
functional status; cognitive function; medical conditions and co-morbidities; special services, <br/>
treatments and interventions; and impairments. Section 1899B(b)(1)(A) of the Act requires that <br/>
such data must be submitted through the applicable reporting provision that applies to each PAC <br/>
provider type using the PAC assessment instrument that applies to the PAC provider. Section <br/>
1899B(a)(1)(B) of the Act additionally requires that these data be standardized and interoperable <br/>
so as to allow for their exchange among health care providers, including PAC providers, to <br/>
ensure coordinated care and improved Medicare beneficiary outcomes as these patients transition <br/>
throughout the care continuum. To enable the interoperable exchange of such information, we <br/>
have adopted certain patient assessment data elements as standardized patient or resident <br/>
assessment data and mapped them to appropriate health IT standards which can support the <br/>
<br/>
7 https://www.cms.gov/Medicare/Provider-Enrollment-and-<br/>Certification/CertificationandComplianc/Downloads/nursinghomedatacompendium_508-2015.pdf. <br/>
<hr/>
<a name=26></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>26</b> <br/>
exchange of this information. For more information, we refer the reader to the CMS website at <br/>
https://del.cms.gov/DELWeb/pubHome. <br/>
5. Privacy Concerns and HIPAA <br/>
The Privacy, Security, and Breach Notification Rules under HIPAA (45 CFR parts 160 <br/>
and 164) support interoperability by providing assurance to the public that PHI as defined in 45 <br/>
CFR 160.103 is maintained securely and shared only for appropriate purposes or with express <br/>
authorization of the individual. For more than a decade, the HIPAA Rules have provided a <br/>
strong privacy and security foundation for the health care system. However, we have heard that <br/>
lack of harmonization between federal and state privacy and security standards can create <br/>
uncertainty or confusion for HIPAA covered entities that want to exchange health information. <br/>
Resources about how the HIPAA Rule permits health care providers and health plans to share <br/>
health information using health IT for purposes like treatment or care coordination is available <br/>
on the HHS OCR website. S<a href="https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/permitted-uses/index.html">ee https://www.hhs.gov/hipaa/for-</a><br/>
<a href="https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/permitted-uses/index.html">professionals/privacy/guidance/permitted-uses/index.html. </a> <br/>
Although barriers to interoperability do exist, HHS and private industry are actively <br/>
working to address them. On June 6, 2018, the HHS Deputy Secretary initiated the Regulatory <br/>
Sprint to Coordinated Care (RS2CC). In support of this effort, the HHS Office of Inspector <br/>
General (OIG) released an RFI on barriers to coordinated care or value-based care, which was <br/>
out for public comment through October 26, 2018 (83 FR 43607). Together, CMS and ONC are <br/>
working to address information blocking via rulemaking. We are actively working to improve <br/>
data standardization, particularly through the use of APIs. And, we are using available policy <br/>
levers to encourage greater adoption of EHR technology and interoperability among PAC <br/>
providers. We provide resources to help providers see how HIPAA and interoperability work <br/>
<hr/>
<a name=27></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>27</b> <br/>
together. And, we are leveraging private sector relationships to find patient matching solutions in <br/>
lieu of a patient identifier. <br/>
F. Summary of Major Provisions<b> </b><br/>
To empower beneficiaries of Medicaid and CHIP FFS programs and enrollees in MA <br/>
organizations, Medicaid and CHIP managed care entities, and QHP issuers in the FFEs (when <br/>
mentioned throughout this proposed rule, this includes QHPs certified by FFEs regardless of <br/>
whether enrollees enroll through the FFE or off the FFE), we are proposing several initiatives to <br/>
break down the barriers that impede patients’ ease of access to their electronic health care <br/>
information; we propose to create and implement new mechanisms for them to access to their <br/>
own health care information, as well as the ability to decide how, when, and with whom to share <br/>
their information. We are proposing to require that a variety of information be made accessible to <br/>
these impacted patients via “openly published” (or simply “open”) APIs– that is, APIs for which <br/>
the technical and other information required for a third-party application to connect to them is <br/>
publicly available. This will provide these patients with convenient access to their health care <br/>
information in accordance with the HIPAA Privacy Rule access standard at 45 CFR 164.524, and <br/>
an increase in their choice of applications with which to access and use their own electronic <br/>
health information, as discussed above, and other information relevant to managing their health, <br/>
enabling open APIs to improve competition and choice as they have in other industries. We <br/>
propose to require MA organizations, Medicaid state agencies, state CHIP agencies, Medicaid <br/>
managed care plans, CHIP managed care entities, and QHP issuers in FFEs to implement open <br/>
APIs consistent with the API technical standards proposed by ONC for adoption by HHS and to <br/>
use content and vocabulary standards adopted by HHS at 45 CFR part 162 and 42 CFR 423.160, <br/>
and proposed by ONC for adoption by HHS at 45 CFR 170.213 (published elsewhere in this <br/>
<b>Federal Register</b>)). <br/>
<hr/>
<a name=28></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>28</b> <br/>
<br/>
Effective coordination and appropriate sharing of enrollee information between health <br/>
plans can reduce the need for providers to write duplicative letters of medical necessity, or it <br/>
could reduce instances of subjecting beneficiaries to unnecessary repetition of step therapy, or <br/>
repeated utilization reviews, risk screenings and assessments. It could also help to streamline <br/>
prior authorization procedures or reduce instances where the clinician might need to intervene <br/>
personally with a payer to ensure his or her patient received the treatment necessary. We are <br/>
proposing to require payers to support beneficiaries in coordinating their own care via payer to <br/>
payer care coordination. In addition to existing care coordination efforts between plans, we <br/>
propose that a plan must, if asked by the beneficiary, forward his or her information to a new <br/>
plan or other entity designated by the beneficiary for up to 5 years after the beneficiary has <br/>
disenrolled with the plan. Such transactions would be made in compliance with applicable laws. <br/>
We are proposing a requirement for MA Plans, Medicaid and CHIP Managed Care entities <br/>
(MCOs, PIHPs, PAHPs), and QHP issuers in FFEs to coordinate care between plans by <br/>
exchanging, at a minimum, the data elements in the United States Core Data for Interoperability <br/>
(USCDI) standard<a href="CMSs.html#28">8</a> at enrollee request at specified times. <br/>
We believe that payers’ ability to share enrollee claims, encounter data, utilization <br/>
history, and clinical health information they may have for their enrollees with one another, as <br/>
well as their ability to share that information with patients and health care providers, when <br/>
approved by the patient and appropriate under applicable law, using interoperable electronic <br/>
means will considerably improve patient access to information, reduce provider burden, and <br/>
reduce redundant and otherwise unnecessary data-related policies and procedures. We are <br/>
proposing to require that all MA organizations, Medicaid and CHIP Managed Care entities <br/>
(MCOs, PIHPs, and PAHPs), and QHP issuers in FFEs (with the exception of stand-alone dental <br/>
<br/>
8 For more information on the USCDI, see https://www.healthit.gov/USCDI. <br/>
<hr/>
<a name=29></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>29</b> <br/>
plans (SADPs)) must participate in a trusted health information exchange network meeting <br/>
criteria for interoperability. Further, we discuss an approach to payer-to-payer and payer-to-<br/>
provider interoperability which leverages such existing trusts networks. <br/>
States and CMS routinely exchange data to support the administration of benefits to <br/>
Medicare-Medicaid dually eligible beneficiaries. This includes “buy-in” data on who is enrolled <br/>
in Medicare, and who is liable for paying the dual eligible beneficiary’s Part A and B premiums. <br/>
Buy-in data exchanges support state, CMS, and Social Security Administration (SSA) premium <br/>
accounting, collections, and enrollment functions. This also includes “MMA” data on dual <br/>
eligibility status (called the “MMA file” after the Medicare Prescription Drug, Improvement and <br/>
Modernization Act of 2003 (MMA) (Pub. L. 108-173, enacted December 8, 2003)), which are <br/>
used in all four Parts of Medicare. We are proposing to establish frequency requirements to <br/>
require all states to participate in daily exchange of buy-in data with CMS by April 1, 2022, and <br/>
to update frequency requirements to require all states to submit MMA file data to CMS daily by <br/>
April 1, 2022. <br/>
We are actively working with our partners throughout HHS to deter the practice of <br/>
information blocking. We believe it would benefit patients to know if their health care providers <br/>
attested negatively to any of the prevention of information blocking attestation statements under <br/>
the Quality Payment Program (QPP) or the Medicare FFS Promoting Interoperability Program. <br/>
In previous testing with patients and caregivers, we have learned that effective use of CEHRT is <br/>
important to them when making informed health care decisions. To address this issue, we are <br/>
proposing to publicly post information about negative attestations on appropriate CMS websites. <br/>
Section 4003 of the Cures Act recognized the importance of making provider digital <br/>
contact information available through a common directory. To facilitate this, CMS has updated <br/>
the National Plan and Provider Enumeration System (NPPES) to be able to capture this digital <br/>
<hr/>
<a name=30></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>30</b> <br/>
contact information. Now that the systems are in place, we seek to increase the number of <br/>
clinicians with valid and current digital contact information available through NPPES. We are <br/>
proposing to publicly identify those clinicians who have not submitted digital contact <br/>
information in NPPES. Further, we are proposing to align program requirements for MA <br/>
organizations, Medicaid state agencies, Medicaid managed care plans, CHIP agencies that <br/>
operate FFS systems, CHIP managed care entities, and QHP issuers in FFEs (with the exception <br/>
of issuers of SADPs) such that each payer/plan issuer would make provider directory <br/>
information publicly available via an API. <br/>
Electronic patient event notifications from hospitals, or clinical event notifications, are <br/>
widely recognized as an effective tool for improving care coordination across settings, especially <br/>
for patients at admission, discharge, and transfer. We are proposing to revise the conditions of <br/>
participation for hospitals (including short-term acute care hospitals, long-term care hospitals <br/>
(LTCHs), rehabilitation hospitals, psychiatric hospitals, children’s hospitals, and cancer <br/>
hospitals) and CAHs to require that these entities send patient event notifications to another <br/>
health care facility or to another community provider. We propose to limit this requirement to <br/>
only those Medicare- and Medicaid-participating hospitals and CAHs that possess EHRs systems <br/>
with the technical capacity to generate information for electronic patient event notifications. <br/>
We also plan to test ways to promote interoperability across the health care spectrum <br/>
through models tested by the Center for Medicare and Medicaid Innovation ("Innovation <br/>
Center"). Innovation Center models offer a unique opportunity to engage with health care <br/>
providers and other entities in innovative ways and to test concepts that have the ability to <br/>
accelerate change in the U.S. health care system, including to promote interoperability. As such, <br/>
we are soliciting public comment on general principles around interoperability within Innovation <br/>
Center models for integration into new models, through provisions in model participation <br/>
<hr/>
<a name=31></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>31</b> <br/>
agreements or other governing documents. In applying these general principles, we intend to be <br/>
sensitive to the details of individual model design, and the characteristics and capacities of the <br/>
participants in each specific model. <br/>
One of the many proposals we considered but did not include in this proposed rule was a <br/>
proposal to make updates to the Promoting Interoperability Program (formerly the Medicare and <br/>
Medicaid EHR Incentive Programs) to encourage eligible hospitals and CAHs to engage in <br/>
certain activities focused on interoperability. This concept was initially introduced in a request <br/>
for public comment in the FY 2019 IPPS/LTCH PPS proposed rule (83 FR 20537 through <br/>
20538). We discussed a possible future strategy in which we would create a set of priority health <br/>
IT or “interoperability” activities that would serve as alternatives to measures in the Promoting <br/>
Interoperability Program. We discussed creating a set of priority health IT activities with a focus <br/>
on interoperability and simplification to reduce health care provider burden while allowing <br/>
flexibility to pursue innovative applications of health IT to improve care delivery. We offered <br/>
three different examples of activities which might be included under such an approach, <br/>
including: <br/>
● Participation in, or serving as, a health information network which is part of the <br/>
Trusted Exchange Framework and Common Agreement (TEFCA); <br/>
● Maintaining an open API which allows persistent access to third parties which enables <br/>
patients to access their health information; and <br/>
● Participating in piloting and testing of new standards that support emerging <br/>
interoperability use cases. <br/>
While we are not proposing this here, we expect to introduce a proposal for establishing <br/>
“interoperability activities” in the FY 2020 IPPS/LTCH PPS rulemaking in conjunction with <br/>
other updates to the Promoting Interoperability Program. To help inform future rulemaking, we <br/>
<hr/>
<a name=32></a><b>CMS-9115-P </b><br/>
<b> </b><br/>
<b> </b><br/>
<b> </b><br/>
<b>32</b> <br/>
invite comments on the concepts discussed above, as well as other ideas for “interoperability <br/>
activities” for which eligible hospitals and CAHs could receive credit in lieu of reporting on <br/>
program measures. <br/>
Finally, we include two RFIs. One related to interoperability and health IT adoption in <br/>