Joining us is Faisal Zain, a renowned expert in medical technology with a career dedicated to advancing the devices that power modern diagnostics and treatment. Today, he’ll help us dissect the new HTI-5 proposed rule from HHS, a significant policy shift that promises to reshape the health IT landscape by rolling back certification requirements while simultaneously tightening rules on data sharing. We’ll explore what this deregulation means for developers, the potential risks of removing AI transparency, and the practical impact of the projected massive cost savings.
The HTI-5 proposal aims to remove or revise nearly 70% of health IT certification criteria. Beyond the stated goal of reducing regulatory hurdles, what are the most significant operational challenges or opportunities this creates for developers, and what specific steps should they start taking now?
This is a seismic shift for the industry. The opportunity is monumental; removing 34 of the 60 certification criteria frees up an incredible amount of resources. Developers can now pivot away from check-the-box compliance and focus on genuine innovation that doctors and patients are asking for. The challenge, however, is navigating this new freedom without clear guideposts. For years, the certification program, for all its faults, provided a framework. Now, developers must self-govern more effectively and differentiate their products based on quality and usability, not just a seal of approval. The first step they should take is to actively participate in the 60-day public comment period to ensure their voice is heard, while internally re-evaluating their product roadmaps to capitalize on this newfound agility.
The rule removes AI transparency requirements like “model cards,” citing no evidence of improved patient outcomes. Can you provide a real-world example of a clinical AI tool where this lack of transparency could create risks, and what metrics should hospitals use to evaluate these tools now?
Absolutely. Imagine a diagnostic AI designed to detect early-stage skin cancer. A “model card” would have disclosed the demographic data—age, ethnicity, skin tone—used to train the algorithm. Without it, a hospital might adopt a tool that performs exceptionally well on fair-skinned patients but is dangerously inaccurate for patients with darker skin because the training data was not diverse. The ASTP/ONC’s argument that there’s no evidence of improved outcomes feels premature; we’re just scratching the surface of clinical AI. In the absence of this mandate, hospitals must become far more sophisticated consumers. They need to demand performance data from vendors that is stratified by their specific patient populations and conduct their own rigorous, real-world validation studies before full-scale deployment.
HHS is tightening information blocking exceptions, claiming they are misused to restrict data. Could you walk us through a common scenario where a developer might use a technical or contractual barrier to block data, and how the proposed changes would specifically prevent that from happening?
This is a critical clarification that many have been waiting for. A common scenario we see involves a large electronic health record vendor creating a complex, non-standardized API for data access. Contractually, they might charge exorbitant per-transaction fees, and technically, they might require a competitor to jump through unnecessary hoops to connect. They aren’t outright denying access, but they are making it so slow and expensive that it effectively blocks the flow of information. The proposed rule directly targets this by clarifying that the definition of information blocking applies to automated access. This means if a system can share data efficiently, it must, and these contrived technical and contractual barriers designed to disadvantage competitors will no longer be a permissible gray area.
The ASTP/ONC projects massive savings of $1.53 billion and 4,000 hours per organization. From a practical standpoint, what does this actually look like for a health tech company? Can you break down where these savings in time and money might come from in their day-to-day operations?
For a health tech company, this is not just an abstract number; it’s a tangible lifeline. That figure of 4,000 hours per organization represents months of work for a small development team that was previously spent on building features solely to meet certification criteria, features that often added little clinical value. This time can now be funneled directly into improving a product’s core functionality or user interface. The $1.53 billion in savings comes from reducing the need for compliance consultants, cutting down on the lengthy and expensive testing and certification processes, and accelerating the time to market. It’s a direct infusion of capital and human resources back into the innovation cycle.
What is your forecast for the future of health data interoperability, given these simultaneous efforts to both deregulate the certification process while also tightening the rules around data sharing and information blocking?
My forecast is for a more dynamic, and frankly, more competitive, health data ecosystem. It might seem contradictory, but this is a very strategic move. By deregulating the product certification side, the administration is lowering the barrier to entry, which will spur a new wave of innovation from smaller, more agile companies. At the same time, by tightening the information blocking rules, they are ensuring that data remains fluid and accessible, preventing new or incumbent players from creating walled gardens. The future isn’t about prescriptive features; it’s about the unimpeded flow of information. Success will no longer be defined by a government certificate, but by a product’s ability to seamlessly and securely share data across the entire healthcare landscape.
