Thursday, June 16, 2022

My Comments on the SANER Rule

Thank you for the opportunity to comment on the CMS 2023 Prospective Payment Rule.  I won't spend a lot of time on introductions.  I'm a highly trained Health IT subject matter expert, and have been employed in the Health IT field for multiple decades.  If you want to learn more, simply go back to the source for these comments and learn more about me. Please note, these are my personal comments on the IPPS rule, not those of my employer or any other organization you might presume I represent.

I am also publicly sharing these comments for anyone else who may have forgotten that these are due tomorrow.

My comments are focused on section M. Condition of Participation (CoP) Requirements for Hospitals and CAHs To Report Data Elements To Address Any Future Pandemics and Epidemics as Determined by the Secretary.

  1. In summary, CMS proposes "to require hospitals and CAHs to report specific data elements to the CDC's National Health Safety Network (NHSN), or other CDC-supported surveillance systems, as determined by the Secretary. 

    I strongly support having the NHSN continue this work.  NHSN has been at the forefront of surveillance and reporting efforts for decades, and that expertise should not be lost in addressing the needs of this sort of reporting or the already established infrastructure supporting tens of thousands of existing connections to reporting facilities and the staff and processes necessary to support and maintain those connections. I’d hate to see NHSN expertise lost in this effort. If it were to go elsewhere within CDC, I would strongly recommend a restructuring based on the existing core NHSN expertise, however, given NHSNs leadership in looking for and adopting new ways to communicate this information (see link below to NHSNLink), that seems unnecessary.  It was already very disruptive to transition this reporting away from NHSN in the first COVID-19 summer under the previous administration.

  2. Section 3. Summary of Costs and Benefits addresses the costs for manual reporting efforts the collected data.  Many facilities will want to automate this process if they have the technical capacity to do so, which has an alternative cost structure. The rationale is that not only is nursing staff time a cost to the facility, but that it also represents anywhere between two weeks (for weekly reporting) and a half a year of nursing time devoted to non-patient care activities, and thus lost revenue.  We already know that during a pandemic emergency, qualified staff are in short supply, so it is not just a matter of making up for the lost staff time.  This represents an opportunity cost that is hard to quantify, but should be a consideration.  Facilities recognize this, and thus many opt to automate these reporting solutions.

    Consider that many hospitals operate at very thin margins.  Published statistics show the average cost of a hospital bed day to be around $2400.  Considering nurse staffing norms between 3 and 5 beds to a nurse, that's between 3 (at weekly reporting) and 42 (for daily reporting) days of lost nursing time, in dollars ~$10,000 for weekly or ~$400,000 for daily reporting of revenue lost due to the nurse not able to care for a patient.

    The data being collection for automating this reporting would not generally come from a single system. To automate requires data collected from between 3 and 5 different hospital systems. Clinical data might come from the EHR, bed capacity from a bed management system, PPE from inventory systems, and medication and vaccination inventory from pharmacy information.  Some facilities might use a combination of manual and automated solutions because they may not have (or need) all of these different systems. 

    Automated solutions are essentially interfaces (a term of art in Health IT) between different health information systems, and NHSN or other CDC entity, but since all reporting is consolidated their must also be a central system that consolidates the data into a single report.  The interfaces themselves require either IT staff effort (or may be purchased from IT vendors), and also require deployment and maintenance to either existing or new hardware.  There are several published estimates for the INITIAL costs for the development of various interfaces, ranging from $3000 to $25,000 depending on complexity and features, as well as the maintenance costs, and some portion of the interface cost may need to go into additional software licenses and infrastructure (e.g., computers) to run those interfaces, as well as IT staff to manage and support them.  There are from 4 to 6 possible interfaces that may be necessary to automate this reporting (thus returning nursing time to the care of patients).  The cost of development for the interface (including first year of operations), could be as much as $250K depending on the approaches used by the facility and again, features and complexity.  Maintenance costs for deployed software can generally be estimated as being somewhere between 10 and 25% of the initial software cost (and some vendors actually compute their annual maintenance prices based on the cost of the initial interface. 

    Assuming a 20% rate for maintenance (a popular number) with minimal associated facility staff time which might be absorbed into routine interface maintenance efforts, this brings the total cost of the interface to around $300K for a two year period, or $500K for a five year period, an amortized cost of around $100K per year over five years.  This effort by the way, also is opportunity loss for the facility, with respect to investing in other interoperability initiatives, such as promoting interoperability.  Just as for any other hospital based professional, there's only so many competent interface people to go around to work on these efforts.   Some of these costs may be offset by the ability of the IT staff to repurpose existing automated solutions, which might reduce these costs to $50K per year (a ballpark back of the napkin estimate) when amortized over a five year period, which would bring the two year cost down around $150K (slightly lower than the cost projected by CMS for manual reporting, but note this response argues that CMS has underrepresented the actual financial impact of the manual cost on hospitals).  This may only be feasible in larger hospitals with more advanced IT staff and capabilities, but does provide a range for the estimation.

    These arguments serve to show that the projected costs of reporting are likely underestimated, either based on the lost revenue due to inability to staff beds due to nursing resources being used for non-direct care activities, or due to somewhat higher to automate such a solution.

  3. The rule states: "For purposes of burden estimates, we do not differentiate among hospitals and CAHs as they all would complete the same data collection."

    Many CAHs have a much lower capacity to support IT innovation, as they provide essential and low margin hospital services in needed areas, and are not able to fund extensive IT departments.  Some CAHs have "a guy who comes in once a week" to work on the IT systems.  Their ability to automate is marginal, and furthermore, it's not just an RN, but probably the most senior nurse at the facility who is doing the reporting, because they are likely one of the few people with access to all of the information.  The reporting in these facilities is a team effort, 2 or 3 people gather data, the reporting nurse consolidates, validates and reports, which also increases the time it can take for reporting. CMS should strongly consider that the burden of this reporting on CAH facilities is going to be much higher just based on the nature of the ways that these facilities operate.

  4. The preamble further says: "Furthermore, we note that this estimate likely overestimates the costs associated with reporting because it assumes that all hospitals and CAHs will report manually."

    Respectfully, I disagree.  As previously noted above, a nurse is a revenue generating employee in a hospital, and the CMS estimates did not account for revenue lost due to engagement in a non-direct care activity.  Just replacing the nurse with another paid at scale does not account for the financial burden of having that person perform non-revenue generating activities.

  5. CMS notes immediately thereafter that "Efforts are underway to automate hospital & CAH reporting that have the potential to significantly decrease reporting burden and improve reliability".  References to such efforts would be very helpful to understand the potential impacts.  Some suggested references follow:

    * NHSNLink developed for NSHS and described at https://www.cdc.gov/csels/phio/exchanging-data-efficiently.html
    * Helios, an HL7 FHIR Accelerator supported by CDC and ONC at https://blog.hl7.org/hl7-launches-helios-fhir-accelerator-for-public-health
    * The HL7 FHIR Situational Awareness for Novel Epidemic Response (SANER) Implementation Guide at https://hl7.org/fhir/uv/saner/.

  6. Also note the two recommendations from the HITAC on SANER (used in all of the above listed references) found here and quoted (and with my emphasis) below:

    a. We recommend that ONC list Situational Awareness interoperability priorities in the ISA and should catalog SANER as well as related standards and IGs; ONC should via work with stakeholders on pilots and early implementation, evaluate and mature standards towards broader adoption.
    b. We recommend that ONC work with stakeholders at HHS to create aligned policy and funding mechanisms to harmonize adoption of a combined situational awareness standard that maximizes readiness and minimizes state-by-state divergence.

    I see the conditions of participation in this rule as being one piece of the aligned policy and would recommend that CMS be prepared to coordinate with other Federal agencies on other pieces (e.g. the Helios effort listed above, USCDI and USCDI+, CDC Grants in aid to the states)

  7. I applaud the efforts that CMS has made to generalize the reporting requirements and learning the lessons from COVID-19 in ways that appropriate to the variety of causes of a pandemic Public Health emergency.  It's good, but honestly more work will be needed to develop the necessary standardized templates that can be used to quickly create measures specific to each PHE, and CMS should collaborate with other existing Federal efforts (e.g., the Helios FHIR Accelerator project, and specifically the Aggregate Data project within Helios) and with ONC/USCDI and USCDI+ to develop these templates, measures and value sets as national standards.  Also, please do not forget that a Pandemic need not be related to a respiratory condition.  Consider AIDS/HIV, or MonkeyPox as examples.

  8. With "that are captured with interoperable data standards and elements", it's clear that CMS understands the need to adopt such standards and data elements in national standards such as those referenced by USCDI.

    The list following this paragraph identifies kinds of things can be captured in a terminology Value Set, maintained readily in VSAC.  Such value sets must be developed and used in measures, and should be adopted from standard vocabularies, but I would recommend that the efforts by the secretary to standardize these value shoulds should focus more on the vocabularies from which they are selected and the standard formats in which they are delivered.  The development of these value sets is more correctly delegated to professionals with relevant background and training, with appropriate governance to enable others outside of the maintaining group to submit new terms for inclusion (much as how vocabularies themselves are developed).  I would encourage CMS to ensure that their are appropriate funding mechanisms to develop and curate such value sets, and investments in VSAC to support the rapid update and easy distribution of them through interoperable solutions.

    * Disease
    * Treatment Devices
    * Vaccine
    * Theraputics (meds or biologics)
    * Co-morbidities

  9. It's unclear whether this text: "The proposed requirements of this section would apply to local, state, and national PHEs as declared by the Secretary." applies to regions under tribal jurisdiction or not.  Given the complexity of jurisdictional governance, I would have appreciated some clarity on this point.

  10. "to include medical record identifier".  Get to work on National Patient ID, please.  In the meantime, investigate existing CDC efforts in application of privacy preserving record links.  It's about time we do away with the dream of longitudinal records through patient matching and move on to the reality of having a unique identifier.  Many of the challenges reported earlier with COVID reporting in public health stem from the inability to walk longitudinally across state, jurisdiction or organizational boundaries.  If you want interoperable data that can provide a national picture, you need a way nationally to identify patients.

  11. On Burden:
    "For purposes of this burden collection, we acknowledge the unknown and the ongoing burdens that may exist even if CMS is not collecting information outside of a declared PHE. We recognize that considerations such as building and maintaining the infrastructure to support readiness are necessary to ensure compliance with this requirement. Therefore, we are soliciting comment on the burden associated with these proposed requirements given the intended flexibility provided in reducing or limiting the scope and frequency of reporting based on the state of the PHE and ongoing circumstances. We are specifically asking for comment on the potential burden associated with the proposed reporting requirements as they might relate to any differences in the public health response to one specific pathogen or infectious disease versus another that would be directly related to the declared PHE. We are also interested in public comments addressing burden estimates (and the potential differences in those estimates) for variations in the required reporting response for a local PHE versus a regional PHE versus a national PHE that might be declared by the Secretary based on the specific circumstances at the time of the declaration."

    Building and maintaining the infrastructure has burdens on Health IT Vendors, and upon their customers (Hospitals and CAHs), as well as on the supporting organizations.The IT Vendor burden is in reality a shifting of focus from vendor determined priorities to national interoperability priorities established by public policy, as their financial burden otherwise flows through and is borne by their customers as a cost of goods and services.  The financial burden on hospitals and CAHs is one which must be borne, and better borne before the next PHE rather than during.  We already well understand the challenge of building the plane while flying it given recent experiences under COVID-19, and the cost of performing such efforts during a PHE surely outweigh those of performing outside one.

    Some of this burden can be reduced by relying on natural aggregators of health information at the local, state, territorial and tribal levels.  CMS should consider enabling health information networks (as defined on ONC rules) including Health Information Exchanges, regional public health entities and supporting organizations (e.g., hospital associations and others) the opportunity to provide services to hospitals and CAHs to support reporting of the requested data to NSHN on behalf of those facilities who want to use them.  This will help by aggregating some of the common infrastructure functions under a single entity, e.g., maintaining compute, storage network and interoperability infrastructure necessary to automate reporting, enable reuse of secured connections to those HINs, and reduce the effort needed to support national reporting.

    I also note that CMS considers only pandemic public health emergencies, but would also remind CMS that other emergencies may also benefit from such a reporting infrastructure.  Forest fires, rolling blackouts, hurricanes and tornados, freezing weather in parts of the country that see it only once a decade or century, all of these emergencies can create a strain on our health infrastructure that appropriately designed system for reporting on situational awareness can address.

    As we've learned, focusing on just beds isn't enough, and reporting multiple separate measures to local, state and national authorities just trebles the burden.  We need to find, dare I say it, a SANER way to accomplish this.

Tuesday, June 7, 2022

Digital Transformation is not computerizing paper forms

This is very related to what we are trying to accomplish with CREDS, and so is sort of a followup to my previous post on CREDS, but is more broadly scoped.

It starts here with this tweet, but not really.  It actually starts with all of the work that people have had to do to mediate between the data in the EHR, and measurement of what that data actually means.

It boils down simply to how one asks questions in order to perform a measurement.

In the early days of quality measurement and/or registry reporting, it was not uncommon to see questions like this:

  • Does this patient qualify for XYZ treatment?
  • Has the patient been prescribed/given XYZ treatment?
  • Is XYZ treatment contraindicated and/or refused?
And, the reporting formats be structured in Yes/No form in some sort of XML or other format.

It's gotten to the point that some of these questions and their possible answers have been encoded in LOINC.  Now, when used for a survey or assessment instrument, that use is fine.  

But for most registry reporting or quality measurement activities, this should really be handled in a different fashion.  This is a start, and can be written in Clinical Quality Language format, or even more simply in a FHIRPath Expression.

  • Does this patient have any of the [XYZ Indications ValueSet]?
  • Has this patient been prescribed/given [XYZ Treatment ValueSet]?
  • Does this patient have [XYZ Treatment Contraindications ValueSet]?

The theme in this restructuring is: Ask the provider what they know and did, and define the logic to compute it.  But even better is to ask the provider what they know and did (and recorded), and have the quality measure reviewer actually do the compute on the quality measure.

Apply normal workflows to keep track of what is learned and done; these shouldn't be interrupted.  I can recall a case where normal workflow added a checkbox to an EHR screen just to get a clinician to acknowledge that they had reviewed and/or reconciled the medication list.

Building these value sets and the logic to evaluate them is hard.  Doing it so that it is interoperable across systems is also hard.  But honestly, the cost per provider to do this is so much less to do it once and do it well, than it is to have hundreds or thousands of systems all need to do this is much more costly, and likely to introduce differences in the compute, and variability in the reported values.

Stop asking for the answers, start asking for the existing evidence to get the answers you need consistently.  And if you cannot get the existing evidence, ask yourself why before asking that it be added to the normal workflow.

   Keith