<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" > <channel> <title>Federal Rulemaking – HLN Consulting LLC</title> <atom:link href="https://www.hln.com/category/federal-rulemaking/feed?utm_source=PANTHEON_STRIPPED&utm_medium=PANTHEON_STRIPPED&utm_campaign=PANTHEON_STRIPPED&utm_term=PANTHEON_STRIPPED" rel="self" type="application/rss+xml" /> <link>https://www.hln.com</link> <description></description> <lastBuildDate>Mon, 28 Oct 2024 15:41:57 +0000</lastBuildDate> <language>en-US</language> <sy:updatePeriod> hourly </sy:updatePeriod> <sy:updateFrequency> 1 </sy:updateFrequency> <generator>https://wordpress.org/?v=6.7.1</generator> <image> <url>https://www.hln.com/wp-content/uploads/2020/09/cropped-HLN-LOGO-4-Twitter-32x32.png</url> <title>Federal Rulemaking – HLN Consulting LLC</title> <link>https://www.hln.com</link> <width>32</width> <height>32</height> </image> <item> <title>ASTP/ONC Releases Draft Federal FHIR Action Plan</title> <link>https://www.hln.com/draft-federal-fhir-action-plan/</link> <dc:creator><![CDATA[Noam Arzt]]></dc:creator> <pubDate>Mon, 28 Oct 2024 15:41:56 +0000</pubDate> <category><![CDATA[DMI]]></category> <category><![CDATA[EHR/PHR]]></category> <category><![CDATA[Electronic Case Reporting (eCR)]]></category> <category><![CDATA[Federal Rulemaking]]></category> <category><![CDATA[FHIR]]></category> <category><![CDATA[HIE & Interoperability]]></category> <category><![CDATA[HL7]]></category> <category><![CDATA[Meaningful Use]]></category> <category><![CDATA[ONC]]></category> <category><![CDATA[Planning]]></category> <category><![CDATA[Public Health]]></category> <category><![CDATA[Blog]]></category> <guid isPermaLink="false">https://www.hln.com/?p=7088</guid> <description><![CDATA[In September 2024, ASTP/ONC released a Draft Federal FHIR Action Plan for public comment - the Federal government has declared FHIR “ready for prime time.” Read a short public health perspective on this plan.]]></description> <content:encoded><![CDATA[<p><img decoding="async" src="https://www.hln.com/wp-content/uploads/2024/10/HealthITgov-ASTP_animated.svg" class="attachment-full size-full wp-post-image" alt="" /></p><div id="themify_builder_content-7088" data-postid="7088" class="themify_builder_content themify_builder_content-7088 themify_builder"> <!-- module_row --> <div class="themify_builder_row module_row clearfix module_row_0 themify_builder_7088_row module_row_7088-0 tb_fzky614"> <div class="row_inner col_align_top" > <div class="module_column tb-column col-full first tb_7088_column module_column_0 module_column_7088-0-0 tb_tu41614"> <div class="tb-column-inner"> <!-- module text --> <div class="module module-text tb_30u441 "> <div class="tb_text_wrap"> <p><span style="font-weight: 400;"><img decoding="async" class="wp-image-7064 alignright" src="https://www.hln.com/wp-content/uploads/2024/10/HealthITgov-ASTP_animated.svg" alt="" width="354" height="73" />In September 2024, the Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology (ASTP/ONC) released a </span><a href="https://www.healthit.gov/isp/about-fhir-action-plan"><span style="font-weight: 400;">Draft Federal FHIR Action Plan</span></a><span style="font-weight: 400;"> for public comment – the Federal government has declared FHIR “ready for prime time.” Aimed in particular at progress by 2026, the plan forms the basis both for identifying and describing the current state of FHIR artifacts and their implementation as well as encouraging Federal agencies </span><i><span style="font-weight: 400;">and their partners</span></i><span style="font-weight: 400;"> to accelerate the implementation of FHIR. </span></p> <p><span style="font-weight: 400;">The Core Components section of the plan describes the currently-published FHIR standards including the current release of FHIR (</span><a href="https://hl7.org/fhir/R4/"><span style="font-weight: 400;">R4</span></a><span style="font-weight: 400;">) and implementation guides currently available for the </span><a href="https://build.fhir.org/ig/HL7/US-Core/"><span style="font-weight: 400;">US Core</span></a><span style="font-weight: 400;">, </span><a href="https://build.fhir.org/ig/HL7/smart-app-launch/app-launch.html"><span style="font-weight: 400;">SMART App Launch</span></a><span style="font-weight: 400;"> and </span><a href="https://spec.smarthealth.cards/"><span style="font-weight: 400;">SMART Health Cards</span></a><span style="font-weight: 400;">, </span><a href="https://build.fhir.org/ig/HL7/bulk-data"><span style="font-weight: 400;">Bulk FHIR</span></a><span style="font-weight: 400;">, </span><a href="https://cds-hooks.hl7.org/"><span style="font-weight: 400;">CDS Hooks</span></a><span style="font-weight: 400;">, and FHIR </span><a href="https://build.fhir.org/ig/HL7/fhir-subscription-backport-ig/"><span style="font-weight: 400;">Subscription</span></a><span style="font-weight: 400;">. Additional components are identified for Public Health and Emergency Response, including the </span><a href="https://build.fhir.org/ig/HL7/fhir-us-ph-library"><span style="font-weight: 400;">US Profiles Library</span></a><span style="font-weight: 400;"> and implementation guides for electronic case reporting (</span><a href="https://build.fhir.org/ig/HL7/case-reporting"><span style="font-weight: 400;">eCR</span></a><span style="font-weight: 400;">), </span><a href="https://build.fhir.org/ig/HL7/fhir-central-cancer-registry-reporting-ig/index.html"><span style="font-weight: 400;">cancer registry reporting</span></a><span style="font-weight: 400;"> and </span><a href="https://build.fhir.org/ig/HL7/cancer-reporting"><span style="font-weight: 400;">pathology data sharing</span></a><span style="font-weight: 400;">, </span><a href="https://build.fhir.org/ig/HL7/fhir-bfdr"><span style="font-weight: 400;">vital reports and fetal death reporting</span></a><span style="font-weight: 400;">, </span><a href="https://build.fhir.org/ig/HL7/fhir-health-care-surveys-reporting-ig/"><span style="font-weight: 400;">healthcare surveys</span></a><span style="font-weight: 400;">, and </span><a href="https://hl7.org/fhir/us/icsr-ae-reporting/"><span style="font-weight: 400;">transfusion and vaccination adverse events</span></a><span style="font-weight: 400;">. While all but the last are “in production” as indicated, there is very little actual use of these standards for public health purposes – at best, the maturity state is indicated as “in pilot.”</span></p> <p><span style="font-weight: 400;">Despite its limited use in public health, this plan is a worthwhile articulation of the Federal government’s intentions and shows strong leadership in this area. As much of public health reporting continues to use </span><a href="https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185"><span style="font-weight: 400;">HL7 v2 messages</span></a><span style="font-weight: 400;"> and the HL7 Clinical Document Architecture (</span><a href="https://hl7.org/cda/"><span style="font-weight: 400;">CDA</span></a><span style="font-weight: 400;">), with limited funding available for migration to newer FHIR standards, complete migration to FHIR will be an uphill battle (see some of our comments on the ASTP/ONC </span><a href="https://www.hln.com/hti-2/"><span style="font-weight: 400;">HTI-2</span></a><span style="font-weight: 400;"> proposed rule). The implementation of FHIR within TEFCA (referenced in the plan) will also help. What we can expect is a much slower, though steady march towards broader adoption of FHIR over at least a five to ten year period.</span></p> <p><span style="font-weight: 400;"> </span></p> </div> </div> <!-- /module text --> </div> </div> </div> <!-- /row_inner --> </div> <!-- /module_row --> </div> <p></p> ]]></content:encoded> </item> <item> <title>A Public Health Perspective on the HTI-2 Proposed Rule</title> <link>https://www.hln.com/hti-2/</link> <dc:creator><![CDATA[Noam Arzt]]></dc:creator> <pubDate>Wed, 09 Oct 2024 14:17:55 +0000</pubDate> <category><![CDATA[AIRA]]></category> <category><![CDATA[CDC]]></category> <category><![CDATA[CSTE]]></category> <category><![CDATA[DMI]]></category> <category><![CDATA[EHR/PHR]]></category> <category><![CDATA[Electronic Case Reporting (eCR)]]></category> <category><![CDATA[Federal Rulemaking]]></category> <category><![CDATA[FHIR]]></category> <category><![CDATA[HIE & Interoperability]]></category> <category><![CDATA[HL7]]></category> <category><![CDATA[Immunization Information System (IIS)]]></category> <category><![CDATA[Meaningful Use]]></category> <category><![CDATA[ONC]]></category> <category><![CDATA[Planning]]></category> <category><![CDATA[Public Health]]></category> <category><![CDATA[Syndromic Surveillance]]></category> <category><![CDATA[Blog]]></category> <guid isPermaLink="false">https://www.hln.com/?p=7063</guid> <description><![CDATA[As the comment period for ASTP/ONC’s HTI-2 proposed rule passes, HLN summarizes some key thoughts from a public health perspective on the Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (HTI-2) Proposed Rule.]]></description> <content:encoded><![CDATA[<p><img decoding="async" src="https://www.hln.com/wp-content/uploads/2024/10/HealthITgov-ASTP_animated.svg" class="attachment-full size-full wp-post-image" alt="" /></p><div id="themify_builder_content-7063" data-postid="7063" class="themify_builder_content themify_builder_content-7063 themify_builder"> <!-- module_row --> <div class="themify_builder_row module_row clearfix module_row_0 themify_builder_7063_row module_row_7063-0 tb_fzky614"> <div class="row_inner col_align_top" > <div class="module_column tb-column col-full first tb_7063_column module_column_0 module_column_7063-0-0 tb_tu41614"> <div class="tb-column-inner"> <!-- module text --> <div class="module module-text tb_30u441 "> <div class="tb_text_wrap"> <p><span style="font-weight: 400;"><a href="https://www.hln.com/wp-content/uploads/2024/10/HealthITgov-ASTP_animated.svg"><img decoding="async" class="wp-image-7064 alignright" src="https://www.hln.com/wp-content/uploads/2024/10/HealthITgov-ASTP_animated.svg" alt="" width="475" height="98" /></a>On August 5, 2024 the Assistant Secretary for Technology Policy/Office of the National Coordinator for Health IT (ASTP/ONC) published for comment in the Federal Register the </span><a href="https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-patient-engagement"><span style="font-weight: 400;">Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (HTI-2) Proposed Rule</span></a><span style="font-weight: 400;">. This mammoth, thousand-page document was a long time in coming and represents just the latest proposed federal rulemaking in fulfillment of Congressional mandates in the </span><a href="https://www.congress.gov/bill/114th-congress/house-bill/34"><span style="font-weight: 400;">21st Century Cures Act</span></a><span style="font-weight: 400;">. </span></p> <p><span style="font-weight: 400;">The proposed rule covered a lot of ground related to certified electronic health records (CEHRT) as well as many other topics related to health information technology. While much of it was not relevant to public health, there were some sections that proposed changes to current rules related to public health and introducing whole new areas of regulation for public health systems and data management processes.</span></p> <p><span style="font-weight: 400;">HLN did not formally comment on this proposed rule, but did provide perspective on the rule’s possible impact on public health to a number of organizations that did submit formal comments (see below). These organizations commented extensively on the myriad of details in the proposed rule. We will not even attempt to summarize all this material, but we do offer a few select comments and observations related to HTI-2, some drawn from the comments referenced below.</span></p> <p><span style="font-weight: 400;">While overall we believe this proposed regulation is moving us in the right direction, here are some pointed observations:</span></p> <ul> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">The scope of HTI-2 and federal rulemaking is limited to data </span><i><span style="font-weight: 400;">interoperability.</span></i><span style="font-weight: 400;"> Remember, there is a lot more to data management in public health agencies (PHAs) than just the submission of data by clinical care and (in some cases) its access by those same data exchange partners. In fact, much of the challenge facing PHAs is not so much </span><i><span style="font-weight: 400;">data </span></i><span style="font-weight: 400;">management (as in CDC’s Data Management Initiative, or DMI), but </span><i><span style="font-weight: 400;">system</span></i><span style="font-weight: 400;"> management, as core public health systems are in dire need of modernization, improvement, and often replacement. This is out of scope for HTI-2. There is some risk that system vendors will focus too narrowly on compliance with ASTP/ONC certification requirements which are related only to interoperability and pay less attention to broader system functionality which may in fact be more essential to public health. With the great variation in PHA capability that still exists, any “one size fits all” certification standard may simply be infeasible, especially when some jurisdictions develop their </span><i><span style="font-weight: 400;">own</span></i><span style="font-weight: 400;"> systems rather than procure vendor solutions.</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">The certification criteria proposed in HTI-2 are just that (and no more than that): certification criteria. For them to be impactful, a government </span><i><span style="font-weight: 400;">program</span></i><span style="font-weight: 400;"> needs to be proposed, finalized, and implemented to </span><i><span style="font-weight: 400;">draw on these certification criteria.</span></i><span style="font-weight: 400;"> For EHRs, that is the remaining CMS </span><a href="https://www.cms.gov/medicare/regulations-guidance/promoting-interoperability-programs"><span style="font-weight: 400;">Promoting Interoperability</span></a><span style="font-weight: 400;"> program which penalizes Medicare providers through a reduced reimbursement rate if they do not meet the requirements. For public health agencies, some federal agency (likely CDC) would need to create a corresponding program once any of these certification criteria for public health systems are finalized. Until that time these would be criteria without regulatory purpose, but one has to start somewhere.</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">HTI-2 proposes some further refinement of the core regulatory language for CEHRT (the existing “(f)(</span><i><span style="font-weight: 400;">n</span></i><span style="font-weight: 400;">)” criteria), and goes on to propose corresponding new criteria (“(f)(2</span><i><span style="font-weight: 400;">n</span></i><span style="font-weight: 400;">)” criteria) with corresponding requirements for public health. Generally speaking, the rule proposes institutionalizing newer versions of existing standards for both interoperability messages and the code sets and terminology that support them that are generally in use already, and we applaud these core updates. It is worth noting that HTI-2 proposes adoption of </span><a href="https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi"><span style="font-weight: 400;">USCDI</span></a><span style="font-weight: 400;"> v4 when v5 is currently defined and would likely be better at furthering the explicit goals of ASTP/ONC.<br /><br /></span>But the devil is in the details, and as the comments referenced below point out, there is a lot of messiness in the proposed rule which makes it difficult to understand exactly who the actors are for certain data exchange transactions, when exactly the proposed regulations (if accepted) would take effect, and more importantly how for public health compliance with any new rules would be funded.Some of the suggested renaming only confuses things further. In some cases, complete migration away from some existing standards (<i>e.g., </i>CDA to FHIR for electronic case reporting and cancer reporting) seems overly aggressive and perhaps even counterproductive.</li> </ul> <ul> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">HTI-2 proposes fairly aggressive implementation of new HL7® standards, including, for example, Fast Healthcare Interoperability Resources (</span><a href="https://hl7.org/fhir/"><span style="font-weight: 400;">FHIR</span></a><span style="font-weight: 400;">); </span><a href="https://hl7.org/fhir/uv/bulkdata/"><span style="font-weight: 400;">Bulk FHIR</span></a><span style="font-weight: 400;">; </span><a href="https://www.hl7.org/fhir/subscription.html"><span style="font-weight: 400;">FHIR subscription</span></a><span style="font-weight: 400;">; and </span><a href="https://smarthealth.cards/en/"><span style="font-weight: 400;">SMART Health Cards</span></a><span style="font-weight: 400;">. These standards are fairly immature, not widely tested, and certainly not widely adopted. The proposed timetable for their implementation seems fairly aggressive for EHRs let alone PHAs who are by and large not funded to implement these new standards.</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">There are some core terms that are used repeatedly in the proposed rule that are not adequately defined, or, the definitions have not been sufficiently vetted (we suppose that’s what the proposed rule is all about). This includes the term “health IT for public health,” “support request, access, and display” of certain health information; and “receipt, validation, parsing, and filtering” as it applies to public health systems. Some of these data activities feel out of scope for HTI-2 (see first comment above).</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">HTI-2 seems to propose some new functionality that does not seem to align with “real world” use and should probably be removed from the final rule. Examples include EHR response to a query for immunization information using existing HL7 v2 standards; Immunization Information System (IIS) bulk query of an EHR; birth reporting to public health; direct patient query of Prescription Drug Monitoring Program (PDMP) systems; required use of the older SFTP transport protocol for Syndromic Surveillance reporting to public health while ignoring the more dominant use of the Minimum Lower Layer Protocol (MLLP) and others; confusion over requirements for laboratory orders (LOI) to be sent to public health..</span></li> </ul> <p><span style="font-weight: 400;">ASTP/ONC received over 270 public comments about this proposed rule, so they have their work cut out for them. Hopefully there will be sufficient engagement with the public health and broader healthcare community over the next year as they evaluate and consider language for a final rule. Stay tuned! We are sure there is much more to come!</span></p> <p><span style="font-weight: 400;">Notable public health related comments drawn on for this post:</span></p> <ul> <li style="font-weight: 400;" aria-level="1"><a href="https://downloads.regulations.gov/HHS-ONC-2024-0010-0205/attachment_1.pdf"><span style="font-weight: 400;">American Immunization Registry Association</span></a><span style="font-weight: 400;"> (AIRA)</span></li> <li style="font-weight: 400;" aria-level="1"><a href="https://downloads.regulations.gov/HHS-ONC-2024-0010-0168/attachment_1.pdf"><span style="font-weight: 400;">Council of State and Territorial Epidemiologists</span></a><span style="font-weight: 400;"> (CSTE)</span></li> <li style="font-weight: 400;" aria-level="1"><a href="https://downloads.regulations.gov/HHS-ONC-2024-0010-0127/attachment_1.pdf"><span style="font-weight: 400;">Health Level Seven</span></a><span style="font-weight: 400;"> (HL7)</span></li> <li style="font-weight: 400;" aria-level="1"><a href="https://www.himss.org/resources/himss-public-comment-response-assistant-secretary-technology-policys-health-information"><span style="font-weight: 400;">Health Information and Management Systems Society</span></a><span style="font-weight: 400;"> (HIMSS)</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Health Information Technology Advisory Committee (HITAC) </span><a href="https://www.healthit.gov/sites/default/files/facas/2024-09-12_HTI-2-PR-TF-2024_Recommendations_Report_Final_Revised_on_9-12-24_w._HITAC_CMNTs_508.pdf"><span style="font-weight: 400;">HTI-2 Proposed Rule Task Force</span></a></li> <li style="font-weight: 400;" aria-level="1"><a href="https://downloads.regulations.gov/HHS-ONC-2024-0010-0206/attachment_1.pdf"><span style="font-weight: 400;">Joint Public Health Informatics Taskforce</span></a><span style="font-weight: 400;"> (JPHIT)</span></li> <li aria-level="1"><a href="https://downloads.regulations.gov/HHS-ONC-2024-0010-0040/attachment_1.pdf" target="_blank" rel="noopener">Pew Charitable Trusts</a> (Pew)</li> </ul> </div> </div> <!-- /module text --> </div> </div> </div> <!-- /row_inner --> </div> <!-- /module_row --> </div> <p></p> ]]></content:encoded> </item> <item> <title>Oh, it’s the other HHS NPRM from this summer…</title> <link>https://www.hln.com/other-hhs-nprm/</link> <dc:creator><![CDATA[Noam Arzt]]></dc:creator> <pubDate>Tue, 03 Sep 2024 20:17:44 +0000</pubDate> <category><![CDATA[DMI]]></category> <category><![CDATA[Federal Rulemaking]]></category> <category><![CDATA[HIE & Interoperability]]></category> <category><![CDATA[Meaningful Use]]></category> <category><![CDATA[Procurement]]></category> <category><![CDATA[Public Health]]></category> <category><![CDATA[Technology]]></category> <category><![CDATA[Blog]]></category> <guid isPermaLink="false">https://www.hln.com/?p=7018</guid> <description><![CDATA[As we pour over the HTI-2 NPRM, HHS recently released the Acquisition of Information Technology; Standards for Health Information Technology proposed rule (HHSAR Case 2023–001). Take a look at our public health perspective.]]></description> <content:encoded><![CDATA[<p><img fetchpriority="high" decoding="async" width="266" height="342" src="https://www.hln.com/wp-content/uploads/2024/09/HHSAR-NPRM-image.png" class="attachment-full size-full wp-post-image" alt="" srcset="https://www.hln.com/wp-content/uploads/2024/09/HHSAR-NPRM-image.png 266w, https://www.hln.com/wp-content/uploads/2024/09/HHSAR-NPRM-image-233x300.png 233w" sizes="(max-width: 266px) 100vw, 266px" /></p><div id="themify_builder_content-7018" data-postid="7018" class="themify_builder_content themify_builder_content-7018 themify_builder"> <!-- module_row --> <div class="themify_builder_row module_row clearfix module_row_0 themify_builder_7018_row module_row_7018-0 tb_fzky614"> <div class="row_inner col_align_top" > <div class="module_column tb-column col-full first tb_7018_column module_column_0 module_column_7018-0-0 tb_tu41614"> <div class="tb-column-inner"> <!-- module text --> <div class="module module-text tb_30u441 "> <div class="tb_text_wrap"> <p><span style="font-weight: 400;"><img loading="lazy" decoding="async" class="size-full wp-image-7020 alignright" src="https://www.hln.com/wp-content/uploads/2024/09/HHSAR-NPRM-image.png" alt="" width="266" height="342" srcset="https://www.hln.com/wp-content/uploads/2024/09/HHSAR-NPRM-image.png 266w, https://www.hln.com/wp-content/uploads/2024/09/HHSAR-NPRM-image-233x300.png 233w" sizes="auto, (max-width: 266px) 100vw, 266px" />Lots of attention is being paid to the HHS </span><a href="https://www.hhs.gov/about/news/2024/07/10/hhs-proposes-hti-2-rule-improve-patient-engagement-information-sharing-public-health-interoperability.html"><span style="font-weight: 400;">Proposed HTI-2 Rule to Improve Patient Engagement, Information Sharing, and Public Health Interoperability</span></a><span style="font-weight: 400;"> which was released for public comment in July 2024. But right on its heals, HHS released the </span><a href="https://www.federalregister.gov/documents/2024/08/09/2024-17096/hhs-acquisition-regulation-acquisition-of-information-technology-standards-for-health-information"><span style="font-weight: 400;">Acquisition of Information Technology;</span></a></p> <p><a href="https://www.federalregister.gov/documents/2024/08/09/2024-17096/hhs-acquisition-regulation-acquisition-of-information-technology-standards-for-health-information"><span style="font-weight: 400;">Standards for Health Information Technology</span></a><span style="font-weight: 400;"> (HHSAR Case 2023–001) proposed rule as well. At its core, this relatively short proposed rule would affirm federal procurement rules first issued by a memorandum in December 2022 that would require that procurements of health information technology by the agency would have to meet the requirements of ASTP/ONC promulgated interoperability standards (</span><a href="https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-B?toc=1"><span style="font-weight: 400;">45 CFR part 170, subpart B</span></a><span style="font-weight: 400;">) and that acquisitions be certified EHR technology (</span><a href="https://www.cms.gov/medicare/regulations-guidance/promoting-interoperability-programs/certified-ehr-technology"><span style="font-weight: 400;">CEHRT</span></a><span style="font-weight: 400;">) if relevant (</span><i><span style="font-weight: 400;">i.e.,</span></i><span style="font-weight: 400;"> when the contractor is an eligible professional or hospital as defined by the HITECH Act).</span></p> <p><span style="font-weight: 400;">My skeptical self tried to find a reason to be suspicious of the need for this proposed regulation, but, frankly, I really can’t find any reason to object. The </span><a href="https://www.healthit.gov/topic/oncs-cures-act-final-rule"><span style="font-weight: 400;">Cures Act</span></a><span style="font-weight: 400;"> provides a strong legislative foundation for promoting agreed-upon interoperability standards, and this proposed regulation is just one more example of a consistent application of that objective. From a public health standpoint, this new procurement rule will help ensure that more purchases are standards-based, as the proposed HTI-2 rule works to promote standards within public health system deployments.</span></p> </div> </div> <!-- /module text --> </div> </div> </div> <!-- /row_inner --> </div> <!-- /module_row --> </div> <p></p> ]]></content:encoded> </item> <item> <title>Immunization Information Systems (IIS): Where are we now and where do we go from here?</title> <link>https://www.hln.com/iis-status/</link> <dc:creator><![CDATA[Noam Arzt]]></dc:creator> <pubDate>Mon, 12 Aug 2024 18:33:05 +0000</pubDate> <category><![CDATA[CDC]]></category> <category><![CDATA[COVID-19]]></category> <category><![CDATA[DMI]]></category> <category><![CDATA[Federal Rulemaking]]></category> <category><![CDATA[Immunization Information System (IIS)]]></category> <category><![CDATA[Meaningful Use]]></category> <category><![CDATA[Planning]]></category> <category><![CDATA[Procurement]]></category> <category><![CDATA[Public Health]]></category> <category><![CDATA[Service-Oriented Architecture (SOA)]]></category> <category><![CDATA[Technology]]></category> <category><![CDATA[Blog]]></category> <guid isPermaLink="false">https://www.hln.com/?p=6968</guid> <description><![CDATA[Where are immunization information systems now and where do we go from here? Read our newest post on this topic and how it relates to data modernization.]]></description> <content:encoded><![CDATA[<p><img loading="lazy" decoding="async" width="1500" height="701" src="https://www.hln.com/wp-content/uploads/2024/04/IISs-original.png" class="attachment-full size-full wp-post-image" alt="" srcset="https://www.hln.com/wp-content/uploads/2024/04/IISs-original.png 1500w, https://www.hln.com/wp-content/uploads/2024/04/IISs-original-300x140.png 300w, https://www.hln.com/wp-content/uploads/2024/04/IISs-original-1024x479.png 1024w, https://www.hln.com/wp-content/uploads/2024/04/IISs-original-768x359.png 768w" sizes="auto, (max-width: 1500px) 100vw, 1500px" /></p><div id="themify_builder_content-6968" data-postid="6968" class="themify_builder_content themify_builder_content-6968 themify_builder"> <!-- module_row --> <div class="themify_builder_row module_row clearfix module_row_0 themify_builder_6968_row module_row_6968-0 tb_fzky614"> <div class="row_inner col_align_top" > <div class="module_column tb-column col-full first tb_6968_column module_column_0 module_column_6968-0-0 tb_tu41614"> <div class="tb-column-inner"> <!-- module text --> <div class="module module-text tb_30u441 "> <div class="tb_text_wrap"> <p><span style="font-weight: 400;">Immunization Information Systems (IIS) are in a precarious position as we come to the end of summer 2024. The urgency of the COVID-19 pandemic is fading, and its funding along with it. The additional funding provided by the Federal government to fight the pandemic cannot be spent after June 30, 2025, which is quickly approaching (though some new funding has just been made available as part of the CDC’s Public Health Infrastructure Grant, or </span><a href="https://www.cdc.gov/infrastructure-phig/about/index.html"><span style="font-weight: 400;">PHIG</span></a><span style="font-weight: 400;">). Federal budget negotiations for FY25 show an uphill battle between the House and Senate with respect to </span><a href="https://www.naccho.org/blog/articles/house-appropriations-committee-releases-fiscal-year-2025-labor-hhs-education-bill"><span style="font-weight: 400;">Health and Human Services (HHS) funding</span></a><span style="font-weight: 400;">. IIS products are aging just at a time when many agencies are trying to determine a modernized, but sustainable direction.</span></p> <p><span style="font-weight: 400;">To help put these many factors into perspective, we have prepared a Force Field Analysis to help describe the state of the country in terms of our ability to provide complete and accessible immunization data via IIS – a key goal of State, Tribal, Local, and Territorial (STLT) health departments. </span></p> <p><span style="font-weight: 400;">In the diagram below,</span></p> <ul> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Driving forces push towards the ideal situation or best possible outcome</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Restraining forces push in the opposite direction towards the worst possible outcome</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Current situation (such as it is) exists because of this equilibrium</span></li> </ul> <p><img loading="lazy" decoding="async" class="aligncenter size-full wp-image-6969" src="https://www.hln.com/wp-content/uploads/2024/08/Fig1.png" alt="" width="345" height="138" srcset="https://www.hln.com/wp-content/uploads/2024/08/Fig1.png 345w, https://www.hln.com/wp-content/uploads/2024/08/Fig1-300x120.png 300w" sizes="auto, (max-width: 345px) 100vw, 345px" /></p> <p><span style="font-weight: 400;">The goal is to reduce the number and power of the restraining forces through some mitigating action(s) while increasing the number and power of the driving forces to push to the desired outcome.</span></p> <p><img loading="lazy" decoding="async" class="aligncenter size-full wp-image-6971" src="https://www.hln.com/wp-content/uploads/2024/08/Fig2.png" alt="" width="636" height="355" srcset="https://www.hln.com/wp-content/uploads/2024/08/Fig2.png 636w, https://www.hln.com/wp-content/uploads/2024/08/Fig2-300x167.png 300w" sizes="auto, (max-width: 636px) 100vw, 636px" /></p> <p><span style="font-weight: 400;">While the Driving Forces may seem compelling, the Restraining Forces can at times be overwhelming. The combined impact of insufficient long-term funding is exacerbated by a COVID “funding cliff;” aging technologies which reduce efficiencies and threaten operations; frustration over inconsistent implementation of technical standards across jurisdictions; and a virulent anti-vax movement and misinformation especially on the Internet. These forces have made it very difficult for IIS projects and immunization programs to maintain their momentum from COVID response.</span></p> <p><span style="font-weight: 400;">In an even broader public health systems context, it feels like major public health informatics initiatives are struggling to align as a concerted effort.</span></p> <p><span style="font-weight: 400;">Just as IIS are struggling to find new, more sustainable solutions, disease surveillance programs are facing the same struggle with </span><a href="https://assets.hln.com/pdf/CSTE24-Landscape_of_Disease_Surveillance_Systems_in_US.pdf"><span style="font-weight: 400;">their core systems</span></a><span style="font-weight: 400;"> for many of the same reasons. And the Data Modernization Initiative (</span><a href="https://www.hln.com/dmi"><span style="font-weight: 400;">DMI</span></a><span style="font-weight: 400;">) does not feel like it is consistently in sync with these two key initiatives; they all feel like they are on their separate but overlapping elliptical orbits around the public health system alignment/coherence goal.</span></p> <p><img loading="lazy" decoding="async" class="aligncenter size-full wp-image-6970" src="https://www.hln.com/wp-content/uploads/2024/08/Fig3.png" alt="" width="439" height="332" srcset="https://www.hln.com/wp-content/uploads/2024/08/Fig3.png 439w, https://www.hln.com/wp-content/uploads/2024/08/Fig3-300x227.png 300w" sizes="auto, (max-width: 439px) 100vw, 439px" /></p> <p><span style="font-weight: 400;">But there are some steps we can take to try to improve the current situation as indicated by the mitigating factors in the force field diagram above:</span></p> <p><b>Stronger advocacy: </b><span style="font-weight: 400;">We need to collectively turn up the heat on Congress to maintain, if not increase, funding for core public health activities and public health informatics projects. </span><b>We can’t let post-pandemic complacency blind us to the dangers that may lay ahead if we are unprepared for the inevitable next public health emergency.</b><span style="font-weight: 400;"> Data management shortcomings and system limitations experienced during COVID-19 can be prevented with prudent investment now.</span></p> <p><b>Modularization of Systems Solutions: </b><span style="font-weight: 400;">Monolithic systems are increasingly difficult to maintain, especially in the face of continually evolving needs. Systems need to be developed in more nimble ways (read Agile) and with a building block architecture (like CDC’s </span><a href="https://www.cdc.gov/surveillance/data-modernization/technologies/edav.html"><span style="font-weight: 400;">Enterprise Data Analytics and Visualization</span></a><span style="font-weight: 400;">, or EDAV) that can allow different features and components to evolve more naturally in different ways. The ongoing focus on application programming interfaces (APIs) and system-to-system interoperability makes the case for modular systems even more compelling.</span></p> <p><b>HTI-2:</b><span style="font-weight: 400;"> The Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (</span><a href="https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-patient-engagement"><span style="font-weight: 400;">HTI-2</span></a><span style="font-weight: 400;">) Proposed Rule has within its provisions, among other things, the alignment of EHR interoperability standards and related technologies with the public health systems with which they interact. While many state-level systems already comply with these standards, a potential Federal rule provides the foundation for other agencies particularly at the local and tribal levels to align more easily as they continue to implement systems.</span></p> <p><b>Training and education: </b><span style="font-weight: 400;">We are all trainers and educators by necessity, and now is the time to continue to write, publish, and speak to whoever will listen about the benefits of public health interventions and the data systems that support these activities. </span></p> </div> </div> <!-- /module text --> </div> </div> </div> <!-- /row_inner --> </div> <!-- /module_row --> </div> <p></p> ]]></content:encoded> </item> <item> <title>CMS IPPS Public Health Reporting and Data Exchange RFI</title> <link>https://www.hln.com/cms-reporting-data-exchange-rfi/</link> <dc:creator><![CDATA[Noam Arzt]]></dc:creator> <pubDate>Fri, 31 May 2024 18:40:05 +0000</pubDate> <category><![CDATA[CDC]]></category> <category><![CDATA[EHR/PHR]]></category> <category><![CDATA[Electronic Case Reporting (eCR)]]></category> <category><![CDATA[Federal Rulemaking]]></category> <category><![CDATA[HIE & Interoperability]]></category> <category><![CDATA[HL7]]></category> <category><![CDATA[Immunization Information System (IIS)]]></category> <category><![CDATA[Meaningful Use]]></category> <category><![CDATA[ONC]]></category> <category><![CDATA[Public Health]]></category> <category><![CDATA[RCKMS]]></category> <category><![CDATA[TEFCA]]></category> <category><![CDATA[Blog]]></category> <guid isPermaLink="false">https://www.hln.com/?p=6886</guid> <description><![CDATA[CMS recently released their Hospital IPPS Policy Changes and Fiscal Year 2025 Rates; Quality Programs Requirements; and Other Policy Changes. It also included the Request for Information (RFI) regarding Public Health Reporting and Data Exchange. Here we address the major RFI questions from a public health perspective.]]></description> <content:encoded><![CDATA[<p><img loading="lazy" decoding="async" width="343" height="71" src="https://www.hln.com/wp-content/uploads/2020/07/image-6.png" class="attachment-full size-full wp-post-image" alt="" srcset="https://www.hln.com/wp-content/uploads/2020/07/image-6.png 343w, https://www.hln.com/wp-content/uploads/2020/07/image-6-300x62.png 300w" sizes="auto, (max-width: 343px) 100vw, 343px" /></p><div id="themify_builder_content-6886" data-postid="6886" class="themify_builder_content themify_builder_content-6886 themify_builder"> <!-- module_row --> <div class="themify_builder_row module_row clearfix module_row_0 themify_builder_6886_row module_row_6886-0 tb_fzky614"> <div class="row_inner col_align_top" > <div class="module_column tb-column col-full first tb_6886_column module_column_0 module_column_6886-0-0 tb_tu41614"> <div class="tb-column-inner"> <!-- module text --> <div class="module module-text tb_30u441 "> <div class="tb_text_wrap"> <section class="col-sm-8 col-md-9 col-lg-9"> <article id="post-2462" class="boxed post-2462 post type-post status-publish format-standard hentry category-aira category-cste category-electronic-case-reporting category-hl7 category-iis"> <div class="post-content-wrapper"> <div class="post-content"> <p><img loading="lazy" decoding="async" class=" wp-image-1723 alignright" src="https://live-new-hln-site.pantheonsite.io/wp-content/uploads/2020/08/CMS.png" alt="" width="314" height="81" srcset="https://www.hln.com/wp-content/uploads/2020/08/CMS.png 368w, https://www.hln.com/wp-content/uploads/2020/08/CMS-300x77.png 300w" sizes="auto, (max-width: 314px) 100vw, 314px" /></p> <p><span style="font-weight: 400;">In April 2024 the Centers for Medicare and Medicaid Services (CMS) released their </span><a href="https://www.govinfo.gov/content/pkg/FR-2024-05-02/pdf/2024-07567.pdf"><span style="font-weight: 400;">Hospital </span></a><a href="https://www.govinfo.gov/content/pkg/FR-2024-05-02/pdf/2024-07567.pdf"><span style="font-weight: 400;">Inpatient Prospective Payment Systems for Acute Care Hospitals and the Long-Term Care </span></a><a href="https://www.govinfo.gov/content/pkg/FR-2024-05-02/pdf/2024-07567.pdf"><span style="font-weight: 400;">Hospital Prospective Payment System and Policy Changes and Fiscal Year 2025 Rates; </span></a><a href="https://www.govinfo.gov/content/pkg/FR-2024-05-02/pdf/2024-07567.pdf"><span style="font-weight: 400;">Quality Programs Requirements; and Other Policy Changes</span></a><span style="font-weight: 400;"> for public comment. Most interesting to public health, however, is a Request for Information (RFI) Regarding Public Health Reporting and Data Exchange (starting on p. 36377). To understand this fully, one needs to have pretty good familiarity with these programs. We will try to address the major RFI questions from a public health perspective.</span></p> <p><span style="font-weight: 400;">The first section of the RFI focuses on how hospitals attest to meeting a public health measure, currently done with just a “yes/no” response. The RFI wonders whether a numerical response with a numerator/denominator, and whether FHIR queries by public health to healthcare systems also measured with a numerator/denominator would be more useful. </span></p> <p><span style="font-weight: 400;">We wonder why there is no reference to the newly-introduced </span><span style="font-weight: 400;">“</span><a href="https://www.healthit.gov/sites/default/files/page/2023-12/HTI-1_Insights_factsheet_508.pdf"><span style="font-weight: 400;">Insights Conditions</span></a><span style="font-weight: 400;">” for certified electronic health record technology. These are measures of interoperability that are incumbent on CEHRT vendors to submit to ONC every six months in aggregate for all users of their certified technology – a single set of metrics reported across all customers, all products, and all versions of the CEHRT (assuming contractual requirements do not prevent this). For public health, the </span><a href="https://www.govinfo.gov/content/pkg/FR-2024-01-09/pdf/2023-28857.pdf"><span style="font-weight: 400;">Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing Final Rule</span></a><span style="font-weight: 400;"> (HT-1) defined a set of measures for immunization reporting, where determining an appropriate numerator and denominator for measurement are straightforward (see our </span><a href="https://www.hln.com/onc-hti-1-final-rule-ph-perspective/"><span style="font-weight: 400;">earlier blog post</span></a><span style="font-weight: 400;"> on this). It seems almost redundant to have the same data reported once by a healthcare organization and again in aggregate by EHR vendors. Perhaps CMS should more explicitly seek to align their measures with these Insights Conditions.</span></p> <p><span style="font-weight: 400;">That being said, </span><i><span style="font-weight: 400;">aside</span></i><span style="font-weight: 400;"> from immunization reporting, the calculation of </span><i><span style="font-weight: 400;">denominators</span></i><span style="font-weight: 400;"> for other types of public health reporting (</span><i><span style="font-weight: 400;">e.g.,</span></i><span style="font-weight: 400;"> electronic laboratory reporting [ELR], electronic case reporting [eCR], syndromic surveillance [SS]) is problematic. You do not know the true occurrence of the disease in your patient population, for instance, to establish a baseline against which you might compare the number of cases reported (the likely numerator). This gets even murkier for, say, syndromic surveillance which may not even involve reporting of identified health data. The measures for SS will likely yield a score of 100% (all encounters sent) or 0% (no encounters sent) and nothing in between. Perhaps an initial focus on the use of standardized coding would be more impactful on the quality of reporting in these areas.</span></p> <p><span style="font-weight: 400;">As for FHIR, we are a bit confused about what CMS is asking. FHIR is not yet widely used for public health reporting, so we have very limited experience and understanding of how FHIR APIs can improve public health reporting. It is likely that FHIR will initially be enabled in public health to support gaps in reporting rather than to replace existing reporting transactions. Examples include the use of bulk FHIR query to get data out of public health registries, and the use of FHIR-based query from public health systems to clinical care for case investigation or follow-up. Since FHIR is not yet a part of </span><i><span style="font-weight: 400;">any</span></i><span style="font-weight: 400;"> established public health reporting it seems premature to discuss it here. Query of clinical systems </span><i><span style="font-weight: 400;">by</span></i><span style="font-weight: 400;"> public health is equally far off, though HL7’s Project Helios does have a </span><a href="https://confluence.hl7.org/pages/viewpage.action?pageId=216238674"><span style="font-weight: 400;">stream of work</span></a><span style="font-weight: 400;"> actively developing and testing standards for this.</span></p> <p><span style="font-weight: 400;">CMS also asks whether it should </span><i><span style="font-weight: 400;">expand</span></i><span style="font-weight: 400;"> public health reporting to new areas, and how it can achieve better completeness for electronic case reporting. It seems that clinical care already has a sufficient amount of reporting to do, and the best way to improve </span><i><span style="font-weight: 400;">completeness</span></i><span style="font-weight: 400;"> of all public health measures – including eCR – is to stay focused on the currently-supported transactions and push for greater compliance with those rather than introduce new ones.</span></p> <p><span style="font-weight: 400;">Next, CMS asks how it can incentivize or support more flexibility in how EHR technology can adapt to changing reporting requirements such as those during COVID pandemic and Mpox outbreak. This is a tough problem as EHR technology is complex and sometimes even convoluted, making it difficult to alter quickly and support adequately. But the best way to improve this nimbleness would be to continue to invest in and leverage central resources and services like the Reportable Conditions Knowledge Management System (</span><a href="https://www.rckms.org/"><span style="font-weight: 400;">RCKMS</span></a><span style="font-weight: 400;">), which provides decision support services regarding reportable conditions, by expanding the reach of RCKMS to include other disease and condition domains. Other shared infrastructure, like the APHL Informatics Messaging Services (</span><a href="https://aimsplatform.com/#/landing"><span style="font-weight: 400;">AIMS</span></a><span style="font-weight: 400;">) and Immunization Gateway (</span><a href="https://www.cdc.gov/vaccines/programs/iis/iz-gateway/overview.html"><span style="font-weight: 400;">IZG</span></a><span style="font-weight: 400;">) also deserve continuing and even expanded investment.</span></p> <p><span style="font-weight: 400;">CMS next asks a question related to certification of public health systems as a way to improve the capability of public health agencies to achieve interoperability with clinical care. One example of such infrastructure is the </span><a href="https://www.immregistries.org/measurement-improvement"><span style="font-weight: 400;">Measurement and Improvement Initiative</span></a><span style="font-weight: 400;"> that has been underway under the auspices of the American Immunization Registry Association (AIRA) and funded by CDC. With participation by </span><a href="https://hl7v2-iz-cdc-testing.nist.gov/iztool/#/home"><span style="font-weight: 400;">NIST</span></a><span style="font-weight: 400;">, this initiative tests Immunization Information Systems compliance with a variety of standards and functional requirements in a voluntary, non-obtrusive way to promote standardization and data quality improvement. A similar initiative could be initiated in other domain areas based on this successful model, though there is danger that certification will focus too much on interoperability to the exclusion of focusing on actual system </span><i><span style="font-weight: 400;">functionality </span></i><span style="font-weight: 400;">for agencies.. </span></p> <p><span style="font-weight: 400;">But CMS has to beware that establishing certification requirements without the concomitant funding would be a disservice to public health agencies and clinical care alike. It is also possible, if not likely, that some public health system vendors will simply choose not to certify their systems at all given the time and expense to do so. With very few choices available to public health agencies this may not improve the overall landscape at all.</span></p> <p><span style="font-weight: 400;">Questions follow regarding incentivising early adoption of FHIR (how can you do that now when the whole CMS program is one of </span><i><span style="font-weight: 400;">dis</span></i><span style="font-weight: 400;">incentives?), and allowing providers to receive credit for the health information exchange (HIE) objective through participation in </span><a href="https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca"><span style="font-weight: 400;">TEFCA</span></a><span style="font-weight: 400;"> (why would it be excluded as currently written?). Finally, CMS wonders whether these measurement programs unduly increase administrative burden on clinical care organizations, and what can be done to minimize this burden. From a strictly public health perspective, while public health </span><i><span style="font-weight: 400;">reporting</span></i><span style="font-weight: 400;"> is at the core of public health surveillance, it’s not clear that the </span><i><span style="font-weight: 400;">measurement </span></i><span style="font-weight: 400;">of this reporting in more detail helps public health in any way. CMS wonders whether a shift to public health </span><i><span style="font-weight: 400;">query</span></i><span style="font-weight: 400;"> of clinical care might reduce the burden on health care organizations. But until the ecosystem around query of EHRs by external organizations is more mature (security, authorization to access data, capacity planning to be able to respond to queries) and public health systems are able to issue queries, this desire is purely aspirational.</span></p> <p><a href="https://www.regulations.gov/commenton/CMS-2024-0131-0025"><span style="font-weight: 400;">Responses</span></a><span style="font-weight: 400;"> to the RFI Regarding Public Health Reporting and Data Exchange are due on June 10, 2024. HLN submitted </span><a href="https://www.hln.com/assets/pdf/Attachment1_IPPSSpring2024-CommentSubmission.pdf"><span style="font-weight: 400;">its own comments</span></a><span style="font-weight: 400;"> as well as participated in the comment submission by <a href="https://www.himss.org/news/himss-calls-significant-investment-public-health-data-modernization-annual-ipps-response" target="_blank" rel="noopener">HIMSS</a> and the <a href="https://www.pewtrusts.org/en/research-and-analysis/speeches-and-testimony/2024/05/31/pew-recommends-steps-to-improve-public-health-data-sharing" target="_blank" rel="noopener" data-saferedirecturl="https://www.google.com/url?q=https://www.pewtrusts.org/en/research-and-analysis/speeches-and-testimony/2024/05/31/pew-recommends-steps-to-improve-public-health-data-sharing&source=gmail&ust=1718981934133000&usg=AOvVaw3nmpP364puGqKZ2-zZycF3">Pew Foundation</a>.</span></p> </div> </div> </article> </section> </div> </div> <!-- /module text --> </div> </div> </div> <!-- /row_inner --> </div> <!-- /module_row --> </div> <p></p> ]]></content:encoded> </item> <item> <title>ONC’s HITAC Releases 2023 Annual Report</title> <link>https://www.hln.com/onc-hitac2023annual-report/</link> <dc:creator><![CDATA[Noam Arzt]]></dc:creator> <pubDate>Mon, 01 Apr 2024 19:27:00 +0000</pubDate> <category><![CDATA[CDC]]></category> <category><![CDATA[DMI]]></category> <category><![CDATA[EHR/PHR]]></category> <category><![CDATA[Electronic Case Reporting (eCR)]]></category> <category><![CDATA[Federal Rulemaking]]></category> <category><![CDATA[HIE & Interoperability]]></category> <category><![CDATA[HL7]]></category> <category><![CDATA[Immunization Information System (IIS)]]></category> <category><![CDATA[Meaningful Use]]></category> <category><![CDATA[ONC]]></category> <category><![CDATA[Public Health]]></category> <category><![CDATA[RCKMS]]></category> <category><![CDATA[Blog]]></category> <guid isPermaLink="false">https://www.hln.com/?p=6592</guid> <description><![CDATA[The Office of the National Coordinator for Health Information Technology (ONC) Health Information Technology Advisory Committee (HITAC) issued its Annual Report for Fiscal Year 2023. Get the highlights of the report.]]></description> <content:encoded><![CDATA[<p><img loading="lazy" decoding="async" width="150" height="194" src="https://www.hln.com/wp-content/uploads/2024/04/ONC2023-report-1-e1712955038206.png" class="attachment-full size-full wp-post-image" alt="" /></p><div id="themify_builder_content-6592" data-postid="6592" class="themify_builder_content themify_builder_content-6592 themify_builder"> <!-- module_row --> <div class="themify_builder_row module_row clearfix module_row_0 themify_builder_6592_row module_row_6592-0 tb_fzky614"> <div class="row_inner col_align_top" > <div class="module_column tb-column col-full first tb_6592_column module_column_0 module_column_6592-0-0 tb_tu41614"> <div class="tb-column-inner"> <!-- module text --> <div class="module module-text tb_30u441 "> <div class="tb_text_wrap"> <p><span style="font-weight: 400;"><img loading="lazy" decoding="async" class="wp-image-6597 alignright" src="https://www.hln.com/wp-content/uploads/2024/04/ONC2023-report-1.png" alt="" width="193" height="250" />The Office of the National Coordinator for Health Information Technology (</span><a href="https://www.healthit.gov/"><span style="font-weight: 400;">ONC</span></a><span style="font-weight: 400;">) Health Information Technology Advisory Committee (</span><a href="https://www.healthit.gov/hitac/committees/health-information-technology-advisory-committee-hitac"><span style="font-weight: 400;">HITAC</span></a><span style="font-weight: 400;">) issued its </span><a href="https://www.healthit.gov/sites/default/files/page/2024-03/HITAC_Annual_Report_for_FY23_508.pdf"><span style="font-weight: 400;">Annual Report for Fiscal Year 2023</span></a><span style="font-weight: 400;"> along with a more lengthy </span><a href="https://www.healthit.gov/sites/default/files/page/2024-03/HITAC_Annual_Report_for_FY23_Supplemental_Background_Research_508.pdf"><span style="font-weight: 400;">appendix of supplemental background information</span></a><span style="font-weight: 400;"> in February 2024. This annual report is required by the </span><a href="https://www.healthit.gov/topic/oncs-cures-act-final-rule"><span style="font-weight: 400;">21st Century Cures Act</span></a><span style="font-weight: 400;">.</span></p> <p><span style="font-weight: 400;">The mail Annual Report document covers some useful areas, including:</span></p> <ul> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">A set of forward-looking “illustrative stories” that highlight how health IT and interoperability can improve the healthcare experience and landscape in the future.</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">A detailed table of health IT infrastructure gaps, opportunities, and recommendations. Some that are noteworthy in their relevance to public health specifically include:</span> <ul> <li style="font-weight: 400;" aria-level="2"><span style="font-weight: 400;">Gaps in Infrastructure and Standards to Support Data Sharing for Public Health Purposes, including recommendations to host a listening session on this topic, and an invitation to the </span><a href="https://rce.sequoiaproject.org/"><span style="font-weight: 400;">TEFCA RCE</span></a><span style="font-weight: 400;"> to meet with the Committee to discuss the emerging public health use cases.</span></li> <li style="font-weight: 400;" aria-level="2"><span style="font-weight: 400;">Information blocking – registries, which recognizes the confusion in the public health ecosystem about whether information blocking rules apply to public health registries in any way and requests additional federal guidance in this area.</span></li> <li style="font-weight: 400;" aria-level="2"><span style="font-weight: 400;">Standards to Support Data Linking and Patient Matching, which seems to come up every year, and the desire for a national strategy especially as the TEFCA network emerges.</span></li> </ul> </li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">A summary of HITAC activities for the year, including its active workgroups, comments on the ONC </span><a href="https://www.hln.com/onc-hti-1-final-rule-ph-perspective/"><span style="font-weight: 400;">HTI-1</span></a><span style="font-weight: 400;"> proposed rule, and the 2022 </span><a href="https://www.hln.com/onc-hitac-ph-taskforce-recommend/"><span style="font-weight: 400;">Public Health Data Systems Task Force</span></a><span style="font-weight: 400;">.</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">A list of benchmarks established by ONC for the advisory committee.</span></li> </ul> <p><span style="font-weight: 400;">A second document provides useful supplemental background information on all of the topics discussed in the annual report, including use of technologies that support public health. The treatment of this topic is fairly cursory, focusing more on gaps in the surveillance landscape than particular technical deficiencies in public health systems or interoperability. A wealth of footnotes makes this document a worthwhile resource.</span></p> <p> </p> </div> </div> <!-- /module text --> </div> </div> </div> <!-- /row_inner --> </div> <!-- /module_row --> </div> <p></p> ]]></content:encoded> </item> <item> <title>ONC HTI-1 Final Rule: A Public Health Perspective</title> <link>https://www.hln.com/onc-hti-1-final-rule-ph-perspective/</link> <dc:creator><![CDATA[Noam Arzt]]></dc:creator> <pubDate>Thu, 22 Feb 2024 20:40:21 +0000</pubDate> <category><![CDATA[CDC]]></category> <category><![CDATA[Clinical Decision Support (CDS)]]></category> <category><![CDATA[DMI]]></category> <category><![CDATA[EHR/PHR]]></category> <category><![CDATA[Electronic Case Reporting (eCR)]]></category> <category><![CDATA[Federal Rulemaking]]></category> <category><![CDATA[HIE & Interoperability]]></category> <category><![CDATA[HL7]]></category> <category><![CDATA[Immunization Information System (IIS)]]></category> <category><![CDATA[Meaningful Use]]></category> <category><![CDATA[ONC]]></category> <category><![CDATA[Public Health]]></category> <category><![CDATA[RCKMS]]></category> <category><![CDATA[Blog]]></category> <guid isPermaLink="false">https://www.hln.com/?p=6515</guid> <description><![CDATA[ONC has issued a final rule for health data, technology, and interoperability (HTI-1). This post comprehensively addresses the key subjects of the regulation from a public health standpoint.]]></description> <content:encoded><![CDATA[<p><img loading="lazy" decoding="async" width="361" height="79" src="https://www.hln.com/wp-content/uploads/2022/11/HealthIT.png" class="attachment-full size-full wp-post-image" alt="" srcset="https://www.hln.com/wp-content/uploads/2022/11/HealthIT.png 361w, https://www.hln.com/wp-content/uploads/2022/11/HealthIT-300x66.png 300w" sizes="auto, (max-width: 361px) 100vw, 361px" /></p><div id="themify_builder_content-6515" data-postid="6515" class="themify_builder_content themify_builder_content-6515 themify_builder"> <!-- module_row --> <div class="themify_builder_row module_row clearfix module_row_0 themify_builder_6515_row module_row_6515-0 tb_fzky614"> <div class="row_inner col_align_top" > <div class="module_column tb-column col-full first tb_6515_column module_column_0 module_column_6515-0-0 tb_tu41614"> <div class="tb-column-inner"> <!-- module text --> <div class="module module-text tb_30u441 "> <div class="tb_text_wrap"> <p><span style="font-weight: 400;"><img loading="lazy" decoding="async" class="wp-image-5711 alignright" src="https://www.hln.com/wp-content/uploads/2022/11/HealthIT.png" alt="" width="297" height="65" srcset="https://www.hln.com/wp-content/uploads/2022/11/HealthIT.png 361w, https://www.hln.com/wp-content/uploads/2022/11/HealthIT-300x66.png 300w" sizes="auto, (max-width: 297px) 100vw, 297px" /></span></p> <p><span style="font-weight: 400;">On February 8, 2024 the Office of the National Coordinator for Health Information Technology (ONC) released the </span><a href="https://www.govinfo.gov/content/pkg/FR-2024-01-09/pdf/2023-28857.pdf"><span style="font-weight: 400;">Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing Final Rule</span></a><span style="font-weight: 400;"> (and corresponding </span><a href="https://www.federalregister.gov/documents/2024/02/08/2024-02519/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and"><span style="font-weight: 400;">Correction document</span></a><span style="font-weight: 400;">) officially in the Federal Register to take effect on March 11, 2024. ONC provides a very nice </span><a href="https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program"><span style="font-weight: 400;">summary of the rule</span></a><span style="font-weight: 400;"> along with recordings and slides from a series of informational webinars held to explain its contents (see </span><a href="https://www.healthit.gov/sites/default/files/page/2024-01/HTI-1%20Final%20Rule%20Overview_Webinar_508.pdf"><span style="font-weight: 400;">overview slides</span></a><span style="font-weight: 400;">).</span></p> <p><span style="font-weight: 400;">The rule has these key topics which will be covered in this post:</span></p> <ul> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Adoption of the updated </span><a href="https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#uscdi-v3"><span style="font-weight: 400;">USCDI version 3</span></a><span style="font-weight: 400;"> which defines core data elements for CEHRT interoperability.</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Updates to Clinical Document Architecture (CDA) Companion Guides (implementation guides).</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Updates to various minimum code set versions under the Program.</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Updates to better support electronic case reporting (eCR)</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Algorithm transparency for certified EHR technology (</span><a href="https://www.cms.gov/medicare/regulations-guidance/promoting-interoperability-programs/certified-ehr-technology"><span style="font-weight: 400;">CEHRT</span></a><span style="font-weight: 400;">) to begin to define the role of artificial intelligence (AI) and other predictive algorithms.</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Based on the requirements of the 21st Century Cures Act, new interoperability-focused reporting metrics (called “</span><a href="https://www.healthit.gov/sites/default/files/page/2023-12/HTI-1_Insights_factsheet_508.pdf"><span style="font-weight: 400;">Insights Conditions”</span></a><span style="font-weight: 400;">) for CEHRT.</span></li> </ul> <p><span style="font-weight: 400;">The final rule also covers enhancements and clarifications to the </span><a href="https://www.healthit.gov/topic/information-blocking"><span style="font-weight: 400;">Information Blocking</span></a><span style="font-weight: 400;"> rules which we will not discuss here. They may or may not apply to public health agencies (PHAs) but may help PHAs get data they need (see a short but interesting previous </span><a href="https://www.networkforphl.org/news-insights/information-blocking-rule-a-new-tool-to-facilitate-public-health-data-collection/"><span style="font-weight: 400;">Network for Public Health Law</span></a><span style="font-weight: 400;"> discussion on this).</span></p> <p><span style="font-weight: 400;">The text of the final rule is nearly 250 pages long in that little Federal Register type (the pre-release version is nearly 1,000 pages, double spaced). There are many, many other changes and enhancements to the Programs covered by this regulation, too many to mention. The text itself not only includes the final decisions with respect to the issues discussed, but a review of comments received by ONC during the comment period which includes ONC’s responses and logic for certain decisions. Following the themes presented in our </span><a href="https://www.hln.com/onc-hti-1-nprm/"><span style="font-weight: 400;">previous post on the HTI-1 Notice of </span><i><span style="font-weight: 400;">Proposed</span></i><span style="font-weight: 400;"> Rulemaking</span></a><span style="font-weight: 400;">, we will comment on those changes that are most relevant to public health.</span></p> <p><span style="font-weight: 400;">Like our last post on the </span><i><span style="font-weight: 400;">proposed</span></i><span style="font-weight: 400;"> rule, this is going to be a little long…</span></p> <p><b>Impact on Public Health</b></p> <p><span style="font-weight: 400;">There was an interesting note about some comments received expressing concern about the impact of these Programs on public health agencies (PHAs), particularly the potential for a long tail of support for old versions of standards which could be handled by “expiration dates,” as well a lack of consideration for the financial cost incurred by PHAs to maintain their side of interoperability connections. ONC acknowledged these concerns, and indicated that some areas of the Program </span><i><span style="font-weight: 400;">did</span></i><span style="font-weight: 400;"> have expiration dates, but really offered no assistance or promise on considering the cost impact on public health.</span></p> <p><b>USCDI</b></p> <p><span style="font-weight: 400;">The final rule updates national data exchange standards for EHRs to use </span><a href="https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#uscdi-v3"><span style="font-weight: 400;">USCDI version 3</span></a><span style="font-weight: 400;"> effective January 1, 2025, though it extends the deadline for the expiration of version 1 to January 1, 2026. There were lots of comments about the timing and contents of USCDI, but ONC was unwavering in its plan. ONC correctly points out that the Final Rule only addresses the ability of CEHRT to exchange USCDI classes and data elements. It does not stipulate requirements for clinical sites actually recording or storing the data. There were lots of comments about inclusion or exclusion of specific data classes and elements in USCDI, but ONC correctly pointed out that the Final Rule was not the place for that discussion and that other processes existed for those comments. We note again that there are no certification criteria in the Program related to public health reporting that reference USCDI so this is not very relevant for public health at this time, other than to continue to set a broader foundation for the availability of data, including new social determinants of health (SDOH) data elements.</span></p> <p><b>Clinical Document Architecture (CDA), Code Sets</b></p> <p><span style="font-weight: 400;">The final rule updates</span> <span style="font-weight: 400;">Clinical Document Architecture (CDA) Companion Guides</span> <span style="font-weight: 400;">(implementation guides) that do not directly affect public health reporting to new versions effective January 1, 2025. Previous versions will expire on January 1, 2026.</span></p> <p><span style="font-weight: 400;">The final rule updates various minimum code set versions under the Program, including CVX (including updates to the codes through June 15, 2022) and NDC codes (including updates to the codes through July 19, 2022) used for immunization reporting; LOINC codes (version 2.40) for laboratory tests; and affirmed their renaming of SOGI to “sexual orientation and gender </span><i><span style="font-weight: 400;">information.</span></i><span style="font-weight: 400;">” All these changes will be effective January 1, 2026.</span></p> <p><b>Electronic Case Reporting (eCR)</b></p> <p><span style="font-weight: 400;">To better support electronic case reporting (eCR), the final rule now incorporates the submission by CEHRT of an electronic initial case report (eICR) in </span><i><span style="font-weight: 400;">either</span></i><span style="font-weight: 400;"> CDA or FHIR formats (using appropriate HL7 implementation guides), and the consumption by the EHR of a Reportability Response (RR) from the Reportable Conditions Knowledge Management Management System (</span><a href="https://www.rckms.org/"><span style="font-weight: 400;">RCKMS</span></a><span style="font-weight: 400;">). The final rule agreed with our suggestion that the CEHRT must only support a RR in a format (CDA or FHIR) corresponding to the format of the eICR it submitted (while supporting a RR in </span><i><span style="font-weight: 400;">either</span></i><span style="font-weight: 400;"> format is certainly a good thing to do). As a precursor, CEHRT must also be able to consume and process case reporting </span><a href="https://ecr.aimsplatform.org/ehr-implementers/triggering/"><span style="font-weight: 400;">trigger codes</span></a><span style="font-weight: 400;"> as defined by the Reportable Conditions Trigger Codes (RCTC) Value Set that are distributed through the Electronic Reporting and Surveillance Distribution (</span><a href="https://build.fhir.org/ig/HL7/case-reporting/electronic_reporting_and_surveillance_distribution_ersd_transaction_and_profiles.html"><span style="font-weight: 400;">eRSD</span></a><span style="font-weight: 400;">) system (though to be compliant, CEHRT does not have to actually support eRSD but can acquire and process the RCTC any way it wishes). All these changes will be effective January 1, 2026.</span></p> <p><span style="font-weight: 400;">There were some interesting comments questioning why ONC was requiring CEHRT to submit standards-compliant case reports even though PHAs are under no requirement to consume them, and in fact many jurisdictional disease surveillance systems cannot. Furthermore, some comments wondered why CEHRT had to support jurisdiction-specific transport requirements. Still others wondered whether the current standards direction for eCR should be modified in favor of standards and strategies that were not public health-specific (like </span><a href="https://smarthealthit.org/"><span style="font-weight: 400;">SMART</span></a><span style="font-weight: 400;"> and </span><a href="https://www.fhir.org/"><span style="font-weight: 400;">FHIR</span></a><span style="font-weight: 400;">). ONC correctly asserted that it cannot solve all of the inconsistencies of our complex healthcare ecosystem, and that it hoped/expected that PHA capabilities would catch up in conformance with CDC’s </span><a href="https://www.cdc.gov/ophdst/public-health-data-strategy/Public_Health_Data_Strategy-final-P.pdf"><span style="font-weight: 400;">Public Health Data Strategy</span></a><span style="font-weight: 400;">, the extended timetable provided in the final rule, and other initiatives. And once again, ONC declined to endorse any specific product (like </span><a href="https://ecr.aimsplatform.org/ecr-now-fhir-app"><span style="font-weight: 400;">eCR Now</span></a><span style="font-weight: 400;">), intermediary (like APHL’s </span><a href="https://aimsplatform.com/#/landing"><span style="font-weight: 400;">AIMS Platform</span></a><span style="font-weight: 400;"> or RCKMS), or real-world testing strategy. </span></p> <p><b>Clinical Decision Support</b></p> <p><span style="font-weight: 400;">As expected, the final rule contains an exhaustive discussion of changes to the treatment of clinical decision support (CDS) in CEHRT. It seems like the core of what was proposed in the NPRM last year was accepted with modifications at the edges. In response to many different comments, ONC does provide some examples of what might be considered Predictive DSI versus evidence-based DSI which were not in the NPRM (starting on p. 1245). As stated in our earlier comments, it is not clear whether there is any impact on public health specifically other than the downstream impact based on changes that may be required of CEHRT in the future. It is worth noting that when asked specifically about patient matching algorithms that use training data (and might be thought of as falling into the definition of predictive DSI), that these systems would likely still be considered evidence-based DSI because they are not really predicting an unknown outcome but scoring the similarity of new data to the training data. </span></p> <p><span style="font-weight: 400;">One interesting aspect of this new rule has to do with the potential impact on Immunization Information Systems (IIS) and their evaluation and forecasting systems, often referred to as clinical decision support (CDS) for Immunizations (CDS-I). These CDS-I systems may be accessible from CEHRT through an application programming interface (API), or the </span><i><span style="font-weight: 400;">results</span></i><span style="font-weight: 400;"> of the evaluation and forecast may be imported into an EHR through a response from an IIS to an electronic query and then used by a clinician to inform a patient’s preventive care. Based on the definitions in the final rule it appears that these CDS-I systems are evidence-based DSI (and not Predictive DSI) judging by how they usually work today. </span></p> <p><span style="font-weight: 400;">But the final rule specifies somewhat extensive “source attribute information” that needs to be made available to users of evidence-based DSI for their review so they can understand how the algorithms work and what data they use. The requirement to provide this information is incumbent on the </span><i><span style="font-weight: 400;">EHR vendor</span></i><span style="font-weight: 400;"> not the CDS creator. So, unless a CDS-I module was being certified by ONC as CEHRT there is no requirement to provide this information. The one exception to this is if the CDS-I creator </span><i><span style="font-weight: 400;">wants</span></i><span style="font-weight: 400;"> the CEHRT to provide the information – then the CEHRT vendor would be obligated to provide it. Additional information on the CDS part of the final rule can be found on the ONC website in both </span><a href="https://www.healthit.gov/sites/default/files/page/2024-01/DSI_HTI1%20Final%20Rule%20Presentation_508.pdf"><span style="font-weight: 400;">presentation slides</span></a><span style="font-weight: 400;"> and a </span><a href="https://www.healthit.gov/sites/default/files/page/2023-12/HTI-1_DSI_fact%20sheet_508.pdf"><span style="font-weight: 400;">fact sheet</span></a><span style="font-weight: 400;">.</span></p> <p><b>Insights Conditions</b></p> <p><span style="font-weight: 400;">A fundamentally new construct introduced in the final rule are the Insights Conditions. These are measures of interoperability that are incumbent on CEHRT vendors to submit to ONC every six months in aggregate for all users of their certified technology – a single set of metrics reported across all customers, all products, and all versions of the CEHRT (assuming contractual requirements do not prevent this). Vendors with a </span><i><span style="font-weight: 400;">very </span></i><span style="font-weight: 400;">small installed base of users would be excluded. Data collection for these metrics would not begin until calendar year 2026 with reporting beginning in 2027. Overall objections to the introduction of Insights Conditions were rejected by ONC as the requirement for introducing them came from Congress in the 21st Century Cures Act and is outside of ONC’s control. ONC noted that, “Another commenter opined </span><i><span style="font-weight: 400;">(their word)</span></i><span style="font-weight: 400;"> on whether engaging with public health agencies to generate some meaningful data might be less burdensome on vendors and their users and may paint a more complete picture of the situation.” Opined? Uh… I think that was me…</span></p> <p><span style="font-weight: 400;">The first two measures being requested by ONC that are relevant to public health relate to data submission to IIS and data query from IIS. As we pointed out in our previous post, the data initially being requested was somewhat confusing, as was the use of “numerator” and “denominator” values to calculate these measures. Based on this feedback, ONC replaced these terms simply with the term “metric” and will collect the data necessary to perform the calculations they desire rather than have the vendors perform the calculations themselves. To somewhat reduce the burden of reporting, ONC is phasing in some of the measures over several years rather than having them all required initially. We had suggested in a comment that IIS might be in a better position to provide these metrics, but ONC expressed concern about the uneven ability of IIS across the country to do so.</span></p> <p><span style="font-weight: 400;">With respect to the first metric – submission of data to an IIS – ONC essentially accepted their proposed details with respect to the data they are requesting and its stratification in age groups (children/adolescents, wisely adjusted to age 18 and below to match Vaccines for Children’s program stratification, and adults), though the implementation of age stratification is delayed to the second year to allow time for implementation. ONC clarified that a transmission should only count once if a successful submission to an IIS is followed by an unsuccessful update attempt, and that messages sent multiple times for the same immunization should also not count as additional transmissions. ONC also confirmed that only message submission errors that result in an “Error (E)” severity should be ignored (</span><i><span style="font-weight: 400;">i.e.,</span></i><span style="font-weight: 400;"> not counted); errors that represent a “Warning (W)” should be counted. If an IIS does not send an acknowledgement message at all back to the EHR for an apparently successful submission that message </span><i><span style="font-weight: 400;">should</span></i><span style="font-weight: 400;"> be counted. ONC also clarified that the metric is counted </span><i><span style="font-weight: 400;">per IIS</span></i><span style="font-weight: 400;">, so if the same immunization was reported to more than one IIS it would count for each one. Finally, ONC clarified that only the transmission of newly administered doses (as opposed to historical doses) should be counted, and those doses need to be both administered </span><i><span style="font-weight: 400;">and</span></i><span style="font-weight: 400;"> transmitted during the reporting period.</span></p> <p><span style="font-weight: 400;">With respect to calculating the number of immunizations administered overall (to be compared with the number submitted to an IIS), ONC clarified that it was not necessary to remove patients who opted out of participating in IIS data submission since the number is relatively small but the burden to exclude them may be greater. ONC further clarified that the number of immunizations administered could be “assigned” to specific IIS either based on the IIS primarily used by the clinical site, or the IIS associated with the clinical site location (and documented as such).</span></p> <p><span style="font-weight: 400;">The second metric for immunization reporting is related to IIS queries for information. ONC clarified that a query response should be counted by the CEHRT if it is received regardless of whether the data is absorbed into the EHR itself. If several queries are required to ultimately receive data (for example, an initial query that requires a follow-up to narrow a set of possible patient matches received from the IIS), </span><i><span style="font-weight: 400;">each</span></i><span style="font-weight: 400;"> query should be counted. Responses from the IIS which indicate an error (severity of “E” included in HL7 v2 RSP message) would be excluded from the count. Both responses with and without an immunization forecast would count. Stratification of the responses by age groups is being delayed to the second year of data collection to lessen the burden on vendors. Data should be included whether the provider administered immunizations during the reporting period or not.</span></p> <p><span style="font-weight: 400;">An additional Insights Condition that is relevant to public health is the the “applications</span></p> <p><span style="font-weight: 400;">supported through certified health IT” measure which asks for information about how external applications (apps) access CEHRT. Public health apps are included as one of the named categories, though I am not exactly sure what types of apps ONC is thinking about (</span><a href="https://ecr.aimsplatform.org/ecr-now-fhir-app"><span style="font-weight: 400;">eCR Now</span></a><span style="font-weight: 400;">?). Apps would need to be “registered” with the CEHRT vendor who would report the “active use” of the application based on characteristics described in the final rule. Additional Insights Conditions focus on the adoption of FHIR (CEHRT response to a FHIR-based query, which could come from a PHA to support, say, case investigation), and bulk FHIR queries sent from CEHRT to another organization (which could be a public health system like an IIS). The presence of these Insights Conditions may encourage or incentivize the deployment of these FHIR-based solutions.</span></p> <p><b>Final Comments</b></p> <p><span style="font-weight: 400;">ONC included a number of requests for information in the original NPRM but offered nothing more than an acknowledgment of having received responses.</span></p> <p><span style="font-weight: 400;">We encourage all those affected stakeholders to examine not only the final rule but additional material summarizing and discussing these developments offered by <a href="https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program">ONC</a> as well as other organizations (like <a href="https://www.himss.org/resources/hti-1-final-rule-five-key-resources-understanding-new-standards-specifications">HIMSS</a>).</span></p> <p><span style="font-weight: 400;"> </span></p> </div> </div> <!-- /module text --> </div> </div> </div> <!-- /row_inner --> </div> <!-- /module_row --> </div> <p></p> ]]></content:encoded> </item> <item> <title>ONC Information Blocking NPRM: Should Public Health Care?</title> <link>https://www.hln.com/onc-nprm-ph-care/</link> <dc:creator><![CDATA[Noam Arzt]]></dc:creator> <pubDate>Mon, 18 Dec 2023 15:02:39 +0000</pubDate> <category><![CDATA[EHR/PHR]]></category> <category><![CDATA[Federal Rulemaking]]></category> <category><![CDATA[HIE & Interoperability]]></category> <category><![CDATA[Meaningful Use]]></category> <category><![CDATA[ONC]]></category> <category><![CDATA[Public Health]]></category> <category><![CDATA[Blog]]></category> <guid isPermaLink="false">https://www.hln.com/?p=6438</guid> <description><![CDATA[The Center for Medicare and Medicaid Services (CMS) recently released a Notice of Proposed Rulemaking (NPRM) on the Establishment of Disincentives for Health Care Providers That Have Committed Information Blocking based on requirements in the 21st Century Cures Act. Get a public health perspective here.]]></description> <content:encoded><![CDATA[<p><img loading="lazy" decoding="async" width="343" height="71" src="https://www.hln.com/wp-content/uploads/2020/07/image-6.png" class="attachment-full size-full wp-post-image" alt="" srcset="https://www.hln.com/wp-content/uploads/2020/07/image-6.png 343w, https://www.hln.com/wp-content/uploads/2020/07/image-6-300x62.png 300w" sizes="auto, (max-width: 343px) 100vw, 343px" /></p><div id="themify_builder_content-6438" data-postid="6438" class="themify_builder_content themify_builder_content-6438 themify_builder"> <!-- module_row --> <div class="themify_builder_row module_row clearfix module_row_0 themify_builder_6438_row module_row_6438-0 tb_fzky614"> <div class="row_inner col_align_top" > <div class="module_column tb-column col-full first tb_6438_column module_column_0 module_column_6438-0-0 tb_tu41614"> <div class="tb-column-inner"> <!-- module text --> <div class="module module-text tb_30u441 "> <div class="tb_text_wrap"> <p><img loading="lazy" decoding="async" class=" wp-image-786 alignright" src="https://www.hln.com/wp-content/uploads/2020/07/image-6.png" alt="" width="251" height="52" srcset="https://www.hln.com/wp-content/uploads/2020/07/image-6.png 343w, https://www.hln.com/wp-content/uploads/2020/07/image-6-300x62.png 300w" sizes="auto, (max-width: 251px) 100vw, 251px" /></p> <p><span style="font-weight: 400;">On November 1, 2023 the Center for Medicare and Medicaid Services (CMS) released a </span><a href="https://www.federalregister.gov/documents/2023/11/01/2023-24068/21st-century-cures-act-establishment-of-disincentives-for-health-care-providers-that-have-committed"><span style="font-weight: 400;">Notice of Proposed Rulemaking</span></a><span style="font-weight: 400;"> (NPRM) on the Establishment of Disincentives for Health Care Providers That Have Committed Information Blocking based on requirements in the 21st Century Cures Act.If finalized, these new rules will allow the HHS Office of Inspector General (OIG) to enforce with disincentives and penalties the </span><a href="https://www.healthit.gov/topic/information-blocking"><span style="font-weight: 400;">Information Blocking</span></a><span style="font-weight: 400;"> rules previously released and in place for nearly a year. The idea of all this is to incentivize the appropriate flow of health information and disincentivize actions that are considered to inappropriately block this flow of information. While any person or organization can raise a claim of information blocking, in his keynote address at the </span><a href="https://sequoiaproject.org/2023-annual-meeting/"><span style="font-weight: 400;">2023 Sequoia Project Annual Meeting</span></a><span style="font-weight: 400;">, Micky Trapathi, the National Coordinator for Health Information Technology, ONC does get a steady stream of complaints almost entirely from consumers (as opposed to other organizations).</span></p> <p><span style="font-weight: 400;">From a public health standpoint, information blocking is just not that big a deal. Many jurisdictions have existing laws, regulations, or policies that govern public health reporting. HIPAA itself has a public health exclusion that permits data exchange for public health purposes without patient consent. So why should public health care about information blocking? Public health can only benefit from an appropriate, unobstructed flow of information. Much of the infrastructure public health agencies use to enable interoperability with clinical care is built on existing clinical care standards, terminology, and technology. The more that these capabilities are exercised unimpeded, the easier it will be for public health to leverage these capabilities for its own use.</span></p> <p><a href="https://www.federalregister.gov/documents/2023/11/01/2023-24068/21st-century-cures-act-establishment-of-disincentives-for-health-care-providers-that-have-committed#open-comment"><span style="font-weight: 400;">Comments</span></a><span style="font-weight: 400;"> on this NPRM can be submitted to CMS through January 2, 2024. </span></p> <p><span style="font-weight: 400;">See the <a href="https://www.pewtrusts.org/-/media/assets/2024/01/onccmscomments-on-information-blocking121923.pdf" target="_blank" rel="noopener" data-saferedirecturl="https://www.google.com/url?q=https://www.pewtrusts.org/-/media/assets/2024/01/onccmscomments-on-information-blocking121923.pdf&source=gmail&ust=1705594256217000&usg=AOvVaw1-AP3qtqkYzctUZ3tCZsn1">letter of support</a> from Pew Charitable Trusts drafted with our input.</span><span style="font-weight: 400;"><br /></span></p> </div> </div> <!-- /module text --> </div> </div> </div> <!-- /row_inner --> </div> <!-- /module_row --> </div> <p></p> ]]></content:encoded> </item> <item> <title>HITAC Task Force Comments on ONC HTI-1 NPRM</title> <link>https://www.hln.com/hitac-onc-hti-1-nprm/</link> <dc:creator><![CDATA[Noam Arzt]]></dc:creator> <pubDate>Thu, 22 Jun 2023 19:20:23 +0000</pubDate> <category><![CDATA[CDC]]></category> <category><![CDATA[DMI]]></category> <category><![CDATA[EHR/PHR]]></category> <category><![CDATA[Electronic Case Reporting (eCR)]]></category> <category><![CDATA[Federal Rulemaking]]></category> <category><![CDATA[HIE & Interoperability]]></category> <category><![CDATA[HL7]]></category> <category><![CDATA[Immunization Information System (IIS)]]></category> <category><![CDATA[Meaningful Use]]></category> <category><![CDATA[ONC]]></category> <category><![CDATA[Public Health]]></category> <category><![CDATA[RCKMS]]></category> <category><![CDATA[Blog]]></category> <guid isPermaLink="false">https://www.hln.com/?p=6003</guid> <description><![CDATA[On June 15, 2023 the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Proposed Rule Task Force 2023 released its recommendations on proposed provisions to the ONC Health IT Certification Program. Get a public health perspective here.]]></description> <content:encoded><![CDATA[<p><img loading="lazy" decoding="async" width="361" height="79" src="https://www.hln.com/wp-content/uploads/2022/11/HealthIT.png" class="attachment-full size-full wp-post-image" alt="" srcset="https://www.hln.com/wp-content/uploads/2022/11/HealthIT.png 361w, https://www.hln.com/wp-content/uploads/2022/11/HealthIT-300x66.png 300w" sizes="auto, (max-width: 361px) 100vw, 361px" /></p><div id="themify_builder_content-6003" data-postid="6003" class="themify_builder_content themify_builder_content-6003 themify_builder"> <!-- module_row --> <div class="themify_builder_row module_row clearfix module_row_0 themify_builder_6003_row module_row_6003-0 tb_fzky614"> <div class="row_inner col_align_top" > <div class="module_column tb-column col-full first tb_6003_column module_column_0 module_column_6003-0-0 tb_tu41614"> <div class="tb-column-inner"> <!-- module text --> <div class="module module-text tb_30u441 "> <div class="tb_text_wrap"> <p><span style="font-weight: 400;"><img loading="lazy" decoding="async" class="wp-image-5711 alignright" src="https://www.hln.com/wp-content/uploads/2022/11/HealthIT.png" alt="" width="251" height="55" srcset="https://www.hln.com/wp-content/uploads/2022/11/HealthIT.png 361w, https://www.hln.com/wp-content/uploads/2022/11/HealthIT-300x66.png 300w" sizes="auto, (max-width: 251px) 100vw, 251px" /></span></p> <p><span style="font-weight: 400;">On June 15, 2023, the </span><a href="https://www.healthit.gov/hitac/committees/hti-1-proposed-rule-task-force-2023"><span style="font-weight: 400;">Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Proposed Rule Task Force 2023</span></a><span style="font-weight: 400;"> released its recommendations on the </span><a href="https://www.federalregister.gov/documents/2023/04/18/2023-07229/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and"><span style="font-weight: 400;">Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Proposed Rule</span></a><span style="font-weight: 400;"> which proposes new </span><span style="font-weight: 400;"> </span><span style="font-weight: 400;">provisions from the </span><a href="https://www.healthit.gov/topic/oncs-cures-act-final-rule#:~:text=ONC's%20Cures%20Act%20Final%20Rule%20supports%20seamless%20and%20secure%20access,secure%20access%20to%20health%20information."><span style="font-weight: 400;">21st Century Cures Act</span></a> <span style="font-weight: 400;">and makes updates to the </span><a href="https://www.healthit.gov/topic/certification-ehrs/about-onc-health-it-certification-program"><span style="font-weight: 400;">ONC Health IT Certification Program</span></a> <span style="font-weight: 400;">(Certification Program). The limited-engagement task force met intensely during April, May, and June 2023 to develop its own set of observations and recommendations which were submitted to the Office of the National Coordinator for Health Information Technology (ONC).</span></p> <p><span style="font-weight: 400;">Though not strictly speaking focused on public health issues, I’d like to offer a few observations of my own regarding their recommendations which do zero in on key public health issues proposed in this NPRM as discussed in our</span><a href="https://www.hln.com/onc-hti-1-nprm/"><span style="font-weight: 400;"> previous blog post</span></a><span style="font-weight: 400;">. </span></p> <p><span style="font-weight: 400;">The first area to comment upon is the new proposal for Insights Conditions, essentially reporting metrics for certified EHR technology mandated by the 21st Century Cures Act but not specified in detail. There are two measures related to public health that are identified in the NPRM, both related to immunization data interoperability. The Task Force expressed its general support for introducing these measures (recommendations 26 – 36) but did not offer any real detailed recommendations concerning the proposed specifics. This mirrored the rather limited discussion that the Task Force conducted during their meetings, and perhaps represents a “missed opportunity” to offer some more meaningful recommendations.</span></p> <p><span style="font-weight: 400;">The second area relates to Electronic Case Reporting (eCR). Here the Task Force seems to focus (in its three recommendations 9 – 11) on just one concept: the need to ensure that real-world testing includes the ability for EHRs to generate and consume reports using </span><i><span style="font-weight: 400;">both</span></i><span style="font-weight: 400;"> the CDA and FHIR standards by requiring transformation from one to <img loading="lazy" decoding="async" class="size-full wp-image-6005 alignleft" src="https://www.hln.com/wp-content/uploads/2023/06/AIMS.png" alt="" width="294" height="137" />the other using a </span><i><span style="font-weight: 400;">commercially-available</span></i><span style="font-weight: 400;"> service. The </span><a href="https://www.aphl.org/programs/informatics/pages/aims_platform.aspx"><span style="font-weight: 400;">APHL AIMS platform</span></a><span style="font-weight: 400;"> through which the vast majority of eCR reports flow has the capability to provide this translation between standards without the use of a </span><i><span style="font-weight: 400;">commercially-available</span></i><span style="font-weight: 400;"> service. In addition, the Task Force recommends that real-world testing for eCR require actual “live” testing with public health agencies. While I recognize the importance of </span><i><span style="font-weight: 400;">real</span></i><span style="font-weight: 400;"> real-world testing, we need to be sure not to create an unfunded mandate for public health to all of a sudden have to support real-world testing so that EHR vendors can satisfy this requirement.</span></p> <p><span style="font-weight: 400;"><img loading="lazy" decoding="async" class="size-full wp-image-6004 alignright" src="https://www.hln.com/wp-content/uploads/2023/06/SMART.png" alt="" width="207" height="84" />One additional minor point: The Task Force did make one recommendation (#50) in response to the SMART Health Links Request for Information. But in this case, it appears that they missed the mark: Task Force members did not seem to appreciate the difference between </span><a href="https://smarthealth.cards/en/"><span style="font-weight: 400;">SMART Health </span><i><span style="font-weight: 400;">Cards</span></i></a><span style="font-weight: 400;"> which represent a limited amount of data embedded in a QR code, and </span><a href="https://docs.smarthealthit.org/smart-health-links/"><span style="font-weight: 400;">SMART Health </span><i><span style="font-weight: 400;">Links</span></i></a><span style="font-weight: 400;"> whose QR code contains a URL which can point to a much more extensive, and updating, set of data about a patient.</span><span style="font-weight: 400;"><br /></span></p> </div> </div> <!-- /module text --> </div> </div> </div> <!-- /row_inner --> </div> <!-- /module_row --> </div> <p></p> ]]></content:encoded> </item> <item> <title>ONC HTI-1 NPRM Through Public Health Eyes</title> <link>https://www.hln.com/onc-hti-1-nprm/</link> <dc:creator><![CDATA[Noam Arzt]]></dc:creator> <pubDate>Wed, 31 May 2023 17:12:35 +0000</pubDate> <category><![CDATA[CDC]]></category> <category><![CDATA[Clinical Decision Support (CDS)]]></category> <category><![CDATA[DMI]]></category> <category><![CDATA[EHR/PHR]]></category> <category><![CDATA[Electronic Case Reporting (eCR)]]></category> <category><![CDATA[Federal Rulemaking]]></category> <category><![CDATA[HIE & Interoperability]]></category> <category><![CDATA[HL7]]></category> <category><![CDATA[Immunization Information System (IIS)]]></category> <category><![CDATA[Meaningful Use]]></category> <category><![CDATA[ONC]]></category> <category><![CDATA[Public Health]]></category> <category><![CDATA[RCKMS]]></category> <category><![CDATA[Blog]]></category> <guid isPermaLink="false">https://www.hln.com/?p=5949</guid> <description><![CDATA[On April 18, 2023 the Office of the National Coordinator for Health Information Technology (ONC) published for comment the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Proposed Rule which proposes new provisions from the 21st Century Cures Act and makes updates to the ONC Health IT Certification Program (Certification Program). Here is a public health perspective.]]></description> <content:encoded><![CDATA[<p><img loading="lazy" decoding="async" width="361" height="79" src="https://www.hln.com/wp-content/uploads/2022/11/HealthIT.png" class="attachment-full size-full wp-post-image" alt="" srcset="https://www.hln.com/wp-content/uploads/2022/11/HealthIT.png 361w, https://www.hln.com/wp-content/uploads/2022/11/HealthIT-300x66.png 300w" sizes="auto, (max-width: 361px) 100vw, 361px" /></p><div id="themify_builder_content-5949" data-postid="5949" class="themify_builder_content themify_builder_content-5949 themify_builder"> <!-- module_row --> <div class="themify_builder_row module_row clearfix module_row_0 themify_builder_5949_row module_row_5949-0 tb_fzky614"> <div class="row_inner col_align_top" > <div class="module_column tb-column col-full first tb_5949_column module_column_0 module_column_5949-0-0 tb_tu41614"> <div class="tb-column-inner"> <!-- module text --> <div class="module module-text tb_30u441 "> <div class="tb_text_wrap"> <p><span style="font-weight: 400;"><img loading="lazy" decoding="async" class="wp-image-5711 alignright" src="https://www.hln.com/wp-content/uploads/2022/11/HealthIT.png" alt="" width="251" height="55" srcset="https://www.hln.com/wp-content/uploads/2022/11/HealthIT.png 361w, https://www.hln.com/wp-content/uploads/2022/11/HealthIT-300x66.png 300w" sizes="auto, (max-width: 251px) 100vw, 251px" />On April 18, 2023, the Office of the National Coordinator for Health Information Technology (ONC) published for comment the </span><a href="https://www.federalregister.gov/documents/2023/04/18/2023-07229/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and"><span style="font-weight: 400;">Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Proposed Rule</span></a><span style="font-weight: 400;"> which proposes new </span><span style="font-weight: 400;"> </span><span style="font-weight: 400;">provisions from the </span><a href="https://www.healthit.gov/topic/oncs-cures-act-final-rule#:~:text=ONC's%20Cures%20Act%20Final%20Rule%20supports%20seamless%20and%20secure%20access,secure%20access%20to%20health%20information."><span style="font-weight: 400;">21st Century Cures Act</span></a> <span style="font-weight: 400;">and makes updates to the </span><a href="https://www.healthit.gov/topic/certification-ehrs/about-onc-health-it-certification-program"><span style="font-weight: 400;">ONC Health IT Certification Program</span></a> <span style="font-weight: 400;">(Certification Program). Weighing in at over 500 pages (the pre-release version), this proposed rule provides some refinements to existing ONC programs, corrections to others, and extensions to yet other provisions. ONC provides additional materials about this proposed rule, including fact sheets, blog posts, and records from topical webinars on their </span><a href="https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program"><span style="font-weight: 400;">website</span></a><span style="font-weight: 400;">. Note especially the information provided about a joint ONC-CDC sponsored informational webinar which took place on May 24, 2023, and is available for playback on the site.</span></p> <p><span style="font-weight: 400;">Though primarily aimed at EHR vendors and their users, there are a number of provisions of this proposed rule that have a direct, if not profound impact on public health systems and operations. There are two main areas where the proposed rule may have a major impact. Sorry, this gets a little long…</span></p> <p><span style="font-weight: 400;">First, ONC proposes some changes to the current certification criterion for</span> <b>electronic case reporting</b><span style="font-weight: 400;"> (</span><a href="https://www.cdc.gov/ecr/index.html"><span style="font-weight: 400;">eCR</span></a><span style="font-weight: 400;">) </span><span style="font-weight: 400;">which to date has not included specific standards. The proposal focuses on an EHR’s ability to consume and process eCR trigger codes; create a standards-compliant electronic initial case report (</span><a href="https://ecr.aimsplatform.org/ehr-implementers/eicr-creation-validation-standards/"><span style="font-weight: 400;">eICR</span></a><span style="font-weight: 400;">) in </span><i><span style="font-weight: 400;">either</span></i><span style="font-weight: 400;"> CDA or FHIR format; and then receive, consume and process a standards-compliant Reportability Response (</span><a href="https://ecr.aimsplatform.org/ehr-implementers/reportability-response-receipt-and-use/"><span style="font-weight: 400;">RR</span></a><span style="font-weight: 400;">) once again in </span><i><span style="font-weight: 400;">either</span></i><span style="font-weight: 400;"> CDA or FHIR format. EHRs then need to be able to transmit the eICR to an appropriate public health system that can receive it.</span></p> <p><span style="font-weight: 400;"><img loading="lazy" decoding="async" class="size-full wp-image-779 alignleft" src="https://www.hln.com/wp-content/uploads/2020/07/image-2.jpeg" alt="" width="353" height="62" srcset="https://www.hln.com/wp-content/uploads/2020/07/image-2.jpeg 353w, https://www.hln.com/wp-content/uploads/2020/07/image-2-300x53.jpeg 300w" sizes="auto, (max-width: 353px) 100vw, 353px" />Today, eICRs are usually generated in CDA format (sometimes with the help of the</span> <a href="https://ecr.aimsplatform.org/ecr-now-fhir-app"><span style="font-weight: 400;">eCR Now</span></a> <span style="font-weight: 400;">application which queries the EHR’s FHIR API and generates the CDA-based eICR) and then transmitted to the Reportable Conditions Knowledge Management System (</span><a href="https://www.rckms.org/"><span style="font-weight: 400;">RCKMS</span></a><span style="font-weight: 400;">) through the APHL AIMS platform. The AIMS platform transports the message as well as the resulting RR using RCKMS data. These central services are capable of converting both the eICR and RR between CDA and FHIR formats. Over time we would expect the eCR process to migrate to a FHIR-based standard end-to-end, but it will take some time for all the pieces to catch up to this newer standard.</span></p> <p><span style="font-weight: 400;">Generally, ONC did a good job of defining new certification criteria to help move eCR forward. Inclusion of consuming and processing the Electronic Reporting and Surveillance Distribution (</span><a href="https://ecr.aimsplatform.org/ehr-implementers/triggering/"><span style="font-weight: 400;">eRSD</span></a><span style="font-weight: 400;">) Specification Library and the eRSD Supplemental Library for trigger code processing is useful, while recognizing that though certification criteria need to identify a </span><i><span style="font-weight: 400;">specific</span></i><span style="font-weight: 400;"> eRSD version, in reality these code sets can change rapidly, especially in an emergency. Across the board, both CDA and FHIR-based specifications for eRSD, as well as eICR and RR, need to continue to be supported for the foreseeable future as proposed. Of course, a clinical site must provide an eICR in the format required by the appropriate agency (CDA or FHIR), not simply pick </span><i><span style="font-weight: 400;">one</span></i><span style="font-weight: 400;"> of these formats on its own. These criteria must reference the appropriate implementation guides which stipulate the required and optional data elements regardless of what USCDI might indicate more broadly. ONC also suggests that EHR technology needs to be recertified once these new criteria go into effect and we support clinical sites being required to use this newly-certified technology. </span></p> <p><span style="font-weight: 400;">Recognition by ONC of the role of the eCR Now application (or its functional equivalent in the future) might also be useful. As a nuance, ONC might stipulate more precisely that not only does a certified EHR need to support </span><i><span style="font-weight: 400;">either</span></i><span style="font-weight: 400;"> CDA or FHIR-based files as proposed, but that the file format of the RR should </span><i><span style="font-weight: 400;">match </span></i><span style="font-weight: 400;">the format of the eICR originally generated (for example, if an EHR supports only CDA-based eCIR generation it should support acceptance of CDA-based RRs).</span></p> <p><span style="font-weight: 400;">It is worth noting that while the NPRM recognizes that decision support for eCR is part of the workflow and process, the use of AIMS as the transport intermediary and RCKMS as </span><i><span style="font-weight: 400;">the</span></i><span style="font-weight: 400;"> proscribed CDS strategy are not part of the recommendation even though it is the dominant architecture for eCR today. I do have mixed feelings about this. Likely ONC wants to ensure that standards-based case reports are transmitted as required by public health agencies that are receiving them. Since AIMS and RCKMS are not </span><i><span style="font-weight: 400;">required</span></i><span style="font-weight: 400;"> by all public health agencies, I suppose it is consistent that ONC would not create a new requirement through this regulation.</span></p> <p><span style="font-weight: 400;">The second major area of interest for public health are the newly-proposed “</span><b>Insights Conditions</b><span style="font-weight: 400;">” (an odd term, to be honest). These refer to a statutory requirement in the Cures Act for ONC to generate metrics for health data interoperability to measure the performance of certified technology in an open and transparent manner. ONC chose to focus initially on interoperability, and public health measures were included in the initial set. If approved as proposed, certified HIT developers will need to submit data every six months on the performance of software they distribute along with the methodology used to generate the data. These measures would be submitted to an as of yet unidentified independent party via a new submission website. Developers whose contracts prevent access to client data would need to renegotiate those contracts!</span></p> <p><span style="font-weight: 400;">There are two measures related to public health that are identified in the NPRM, both related to immunization data interoperability. The first measure is focused on immunization data </span><i><span style="font-weight: 400;">submission</span></i><span style="font-weight: 400;"> to immunization information systems (</span><a href="https://www.cdc.gov/vaccines/programs/iis/about.html"><span style="font-weight: 400;">IIS</span></a><span style="font-weight: 400;">). ONC claims that current information on this is insufficient, especially when they ask clinical sites about it via surveys. ONC wants to know “whether and to what extent providers are using their certified health IT to electronically send and receive public health information to and from public health agencies.” While the current compliance data that ONC collects on “active engagement” does not provide statistics, public health agencies certainly know the landscape of data submission for clinical sites submitting data. One has to wonder whether engaging with public health to generate some meaningful data might not be less of a burden on EHR vendors and their users and perhaps paint a more complete picture of the situation.</span></p> <p><span style="font-weight: 400;">To achieve this measure, vendors will need to submit a numerator which is the number of immunizations submitted electronically to public health during the reporting period. Submissions that failed due to error (as reported back by the IIS in an HL7 v2 ACK message) would be subtracted. ONC wonders whether an immunization submitted to more than one IIS should count more than once. I don’t see why not, if this is a measure of interoperability. They also ask whether resubmissions to correct errors should count (they think they should). I see no reason why </span><i><span style="font-weight: 400;">successful</span></i><span style="font-weight: 400;"> resubmissions of </span><i><span style="font-weight: 400;">rejected </span></i><span style="font-weight: 400;">transactions</span><span style="font-weight: 400;"> should not count since they were removed when unsuccessful. The denominator is the total number of immunizations administered. Both the numerator and denominator would be provided in total, and then segmented by children and adults. ONC states that, “Reporting by these subgroups will assist in interpreting the data and in creating public awareness that could inform IISs and others in the public health community about the progress being made in immunization data exchange… The data collected for this proposed measure would enable ONC to calculate the percent of immunizations administered where the information was electronically submitted to an IIS.”</span></p> <p><span style="font-weight: 400;">Note that there are a number of important subtleties with respect to the proposed measures. Remember, an EHR may be just as likely to send a patient’s immunization </span><i><span style="font-weight: 400;">history</span></i><span style="font-weight: 400;"> as much as a patient’s </span><i><span style="font-weight: 400;">newly administered dose</span></i><span style="font-weight: 400;">, or even both. In fact, an EHR can send the history over and over again. So in fact it is quite possible (or even likely) that the total number of doses submitted electronically </span><i><span style="font-weight: 400;">exceeds</span></i><span style="font-weight: 400;"> the number of doses administered. It might be necessary to either ensure that the count of doses sent electronically only include those doses tagged as newly administered which is certainly possible but which complicates the data collection process. This concern could be mitigated by either making sure they are also included in the denominator or excluding them entirely. Note that historical doses may have questionable data quality and should have already been reported previously (even by a different provider).</span></p> <p><span style="font-weight: 400;">Another issue is the potential that while only transmission of </span><i><span style="font-weight: 400;">fatal</span></i><span style="font-weight: 400;"> errors are excluded from the count, the transmissions that had </span><i><span style="font-weight: 400;">warnings</span></i><span style="font-weight: 400;"> of potential issues from the IIS (via HL7 v2 ACK messages) might in fact be resubmitted with some additional or corrected information. This has the potential to inflate the numerator in the calculation unless the vendor knows enough to exclude these resubmissions from the count. Keep in mind that </span><i><span style="font-weight: 400;">any</span></i><span style="font-weight: 400;"> double counting of doses administered, especially in the numerator, makes all of the data suspect. </span><span style="font-weight: 400;">To implement this right, an EHR must store the ACK(s) for each dose; and if the dose has at least one good ACK from an IIS, it can be counted in the numerator. Importantly, without a requirement to store the ACK, ONC would have no way to reliably audit a vendor’s reported metric. If storing ACKs is a requirement (as it must be in order to ensure the integrity of the metric), then ONC will also need to ensure that there is a standards-based way to store ACKs in FHIR resources.</span></p> <p><span style="font-weight: 400;">To make matters worse, some providers delete a dose and then recreate it in order to edit a dose in their EHR. If a dose is deleted, logically it should be removed from the numerator and denominator going forward, but this could cause headaches for the data analysis at ONC if deleted doses have already been reported. Another potential problem is if two practices merge, or if a practice using two EHRs merges them into one, or if a practice simply migrates to a new EHR. ONC will need to provide guidance on exactly how doses should be counted in the metrics once they have migrated from one EHR to another.</span></p> <p><span style="font-weight: 400;">The second measure is related to “Immunization History and Forecast,” in other words, query of an IIS. The numerator would be the total number of query responses received. Queries that failed due to error (as reported back by the IIS in an HL7 v2 ACK message) would be subtracted. ONC asks whether both queries with and without a forecast should count. Given that it’s the EHR that specifies what kind of data it wants in return, and there are use cases for both including and excluding an immunization forecast, I see no reason why both types of queries should not be included. There would be two denominators reported: first, the total number of queries; and second, the total number of encounters which might actually have a secondary use of measuring potential “</span><a href="https://www.cdc.gov/vaccines/hcp/admin/reminder-sys.html"><span style="font-weight: 400;">missed opportunities</span></a><span style="font-weight: 400;">” for immunization services. Both the numerator and denominators would be provided in total, and then segmented by children and adults. ONC states that “We propose to add this denominator to the measure proposed by the Urban Institute (the entity that developed the draft measures) to provide data on the total number of query responses that are and are not successfully received from an IIS.” I’m not sure I really know what that means. </span></p> <p><span style="font-weight: 400;">Note that there is also a proposed measure for the use of Bulk FHIR, but it’s unrelated to public health reporting. Though public health is working on a Bulk FHIR query for immunization data from IIS as part of the </span><a href="http://www.hl7.org/helios/"><span style="font-weight: 400;">Helios FHIR Accelerator</span></a><span style="font-weight: 400;">, the proposed measures are related to EHRs </span><i><span style="font-weight: 400;">providing</span></i><span style="font-weight: 400;"> data through FHIR, not querying other systems for data.</span></p> <p><span style="font-weight: 400;">Reporting would not be necessary for any site that did not administer immunizations. To reduce the burden on smaller vendors, they would be excluded from this measurement requirement if their products are used in fewer than fifty hospitals </span><i><span style="font-weight: 400;">or</span></i><span style="font-weight: 400;"> by fewer than 500 users. I assume that a developer would submit single, aggregate numbers for numerator and denominator across </span><i><span style="font-weight: 400;">all</span></i><span style="font-weight: 400;"> EHR sites that were included. I also assume that this data is not being collected for epidemiological study – and would not be available for that purpose – but only as a measure of the effectiveness of the certified technology.</span></p> <p><span style="font-weight: 400;">I must admit, I am having a hard time accepting that these measures will really tell us anything we probably don’t already know with respect to interoperability between EHRs and IIS. On the data submission side, this is a requirement in many jurisdictions and is monitored closely as a function of vaccine inventory management and vaccine distribution through programs like the </span><a href="https://www.cdc.gov/vaccines/programs/vfc/index.html"><span style="font-weight: 400;">Vaccine for Children</span></a> <span style="font-weight: 400;">(VFC) program. For query, there are such varying clinical practices about when a query to an IIS is even appropriate that I am not sure how we will be able to interpret the data. The proposed metrics (based on the comments above) are actually quite complex to generate consistently. I would recommend against any further stratification or segmentation of the data as it will likely introduce even more burden on both vendors and providers. As is, I feel many vendors will have to enlist their customers to help them access the data and interpret it properly – I think there is a large potential for misunderstanding as some EHR clients do not necessarily use the software as the vendor intended. Remember, vendors will need to generate this data </span><i><span style="font-weight: 400;">retrospectively</span></i><span style="font-weight: 400;"> from data stored in the EHR which may or may not be a simple feat.</span></p> <p><span style="font-weight: 400;">Here are some additional items included in the proposed rule that public health agencies and stakeholders should review and comment on if desired:</span></p> <ul> <li style="list-style-type: none;"> <ul> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Changes to </span><b>minimum code sets</b><span style="font-weight: 400;"> references in the regulations. For public health, this includes CVX and NDC codes which are related to immunization reporting. This is a structural problem in part: regulations (apparently) need to stipulate specific code set versions, but these code sets are </span><i><span style="font-weight: 400;">constantly</span></i><span style="font-weight: 400;"> changing as new vaccines are introduced and others fall away.</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Update to a new version of the United States Core Data for Interoperability (</span><a href="https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi"><b>USCDI</b></a><span style="font-weight: 400;">). Though there are no EHR certification criteria for public health that reference USCDI yet, this may be something more relevant in the future. The proposal includes a refresh of relevant Clinical Document Architecture (CDA) implementation guide (IG) versions.</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Changes to the notion of </span><b>clinical decision support</b><span style="font-weight: 400;"> (</span><b>CDS</b><span style="font-weight: 400;">). The proposal replaces CDS with “decision support interventions (DSI)” and more specifically “predictive DSI.” Users would need to determine (potentially with the help of industry groups) that a DSI is fair, appropriate, valid, effective, and safe (FAVES). Vendors would need to identify risk management practices – risk analysis, risk management, and governance. Users should be able to identify if certain data elements were used in the DSI. The proposed rule makes additional distinctions between a “predictive DSI” which is derived/informed by training or example data (like a probabilistic person matching engine) and an evidence-based DSI (based on rules from experts, like a deterministic matching engine). While not aimed explicitly at public health, changes in this terminology and a refocus of ONC on CDS in EHRs might impact CDS as used by public health (for </span><a href="https://www.hln.com/ice"><span style="font-weight: 400;">immunization evaluation and forecasting</span></a><span style="font-weight: 400;">, for instance).</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">Suggested changes to code sets and data elements related to </span><b>sexual orientation and gender identity</b><span style="font-weight: 400;"> (</span><a href="https://www.cdc.gov/hiv/clinicians/transforming-health/health-care-providers/collecting-sexual-orientation.html"><b>SOGI</b></a><span style="font-weight: 400;">), now proposed to be referred to as sexual orientation and gender information, which may have an impact on public health registry compatibility and longitudinal data analysis as these codes change over time.</span></li> <li style="font-weight: 400;" aria-level="1"><span style="font-weight: 400;">ONC included some brief Requests for Information related to specific topics that may have a public health impact:<br /></span><br /> <ul> <li style="font-weight: 400;" aria-level="2"><b>Lab reporting</b><span style="font-weight: 400;"> RFI: Wondering whether laboratory information systems and their use in lab orders and results processing should be certified based on a Congressional mandate to ONC to study this question. Public health lab reporting certification criteria are explicitly mentioned in this section. An interesting question is the relative importance of HL7v2, CDA, and FHIR standards for this activity.</span></li> <li style="font-weight: 400;" aria-level="2"><b>Pharmacy </b><span style="font-weight: 400;">RFI: Wondering, among other things, if pharmacy interoperability for prescribing and fulfillment should be subject to regulation. More consistent use of standards in this arena may benefit public health indirectly, though the impact on prescription drug monitoring programs (</span><a href="https://www.cdc.gov/drugoverdose/pdmp/index.html"><span style="font-weight: 400;">PDMP</span></a><span style="font-weight: 400;">) may be more direct.</span></li> </ul> </li> </ul> </li> </ul> <ul> <li style="list-style-type: none;"> <ul> <li style="list-style-type: none;"> <ul> <li aria-level="2"><b>FHIR</b><span style="font-weight: 400;"> RFI: This RFI addresses several capabilities of FHIR, including appointment scheduling through </span><a href="https://github.com/smart-on-fhir/smart-scheduling-links"><span style="font-weight: 400;">SMART Scheduling Links</span></a><span style="font-weight: 400;"> (COVID appointment scheduling automation problems were explicitly called out); </span><a href="https://docs.smarthealthit.org/smart-health-links/"><span style="font-weight: 400;">SMART Health Links</span></a><span style="font-weight: 400;"> (once again, prominent during the pandemic for the use of its predecessor, </span><a href="https://smarthealth.cards/en/"><span style="font-weight: 400;">SMART Health Cards</span></a><span style="font-weight: 400;">, in providing COVID immunization histories); and </span><a href="https://cds-hooks.org/"><span style="font-weight: 400;">CDS Hooks</span></a><span style="font-weight: 400;">, demonstrated in public health clinical decision support for immunizations.</span></li> </ul> </li> </ul> </li> </ul> <p><span style="font-weight: 400;">ONC is accepting </span><a href="https://www.regulations.gov/commenton/HHS-ONC-2023-0007-0001"><span style="font-weight: 400;">comments</span></a><span style="font-weight: 400;"> on this NPRM through June 20, 2023 (see optional </span><a href="https://www.healthit.gov/sites/default/files/page/2023-05/ONC_HTI-1_ProposedRule_PublicCommentTemplate_508.docx"><span style="font-weight: 400;">comment template document</span></a><span style="font-weight: 400;">).</span></p> </div> </div> <!-- /module text --> </div> </div> </div> <!-- /row_inner --> </div> <!-- /module_row --> <!-- module_row --> <div class="themify_builder_row module_row clearfix module_row_1 themify_builder_5949_row module_row_5949-1 tb_a08y359"> <div class="row_inner col_align_top" > <div class="module_column tb-column col-full first tb_5949_column module_column_0 module_column_5949-1-0 tb_5efg361"> <div class="tb-column-inner"> <!-- module text --> <div class="module module-text tb_ocxr793 "> <div class="tb_text_wrap"> <p><strong>Send us feedback about this blog</strong></p> </div> </div> <!-- /module text --> <!-- module text --> <div class="module module-text tb_rset364 "> <div class="tb_text_wrap"> [contact-form-7] </div> </div> <!-- /module text --> </div> </div> </div> <!-- /row_inner --> </div> <!-- /module_row --> </div> <p></p> ]]></content:encoded> </item> </channel> </rss>