CHALLENGE 08
Ignoring Policy, Standards, and Interoperability Until Too Late
A Health IT company can have strong technology, a compelling use case, and interested provider buyers—and still discover that policy, interoperability, data requirements, or regulatory expectations create commercial barriers the product team did not anticipate.
Healthcare technology does not operate in isolation.
Hospitals and health systems work inside an ecosystem shaped by interoperability standards, data-sharing requirements, federal policy, privacy expectations, reimbursement rules, governance structures, and technical architectures that continue to evolve.
For vendors, these forces can influence product design, implementation burden, integration complexity, evidence requirements, and even whether a solution is commercially viable for a particular provider.
Waiting until late in the sales process to understand those requirements can create expensive surprises.
In Health IT, the environment around the product can be just as important as the product itself.
Seller’s Lens vs. Buyer’s Lens
Health IT companies naturally focus on what their product can do. Providers also need to understand whether the solution fits the policy, interoperability, data, and technical environment in which it will have to operate.
Seller’s Lens
“Our technology solves the problem.”
The seller sees:
- strong product capabilities;
- differentiated functionality;
- successful demonstrations;
- measurable outcomes;
- API availability;
- integration capability;
- access to required data;
- and a product roadmap that supports growth.
From the seller’s perspective, technical capability demonstrates readiness.
Buyer’s Lens
“Can this operate responsibly inside our ecosystem?”
The provider is asking:
- How will the solution exchange data with our existing systems?
- Which interoperability standards does it support?
- What data elements are required?
- How does it fit our information-sharing obligations?
- Will implementation create new technical dependencies?
- What policy or regulatory changes could affect the solution?
- How will future standards changes be handled?
- Could this create compliance, workflow, or operational risk?
Product capability matters. Ecosystem compatibility determines whether that capability can actually be used.
Why This Becomes a GTM Problem
When policy, standards, and interoperability are treated as technical details to resolve after buyer interest is established, commercial teams may discover late that the solution does not fit the provider’s environment as easily as expected.
Integration Is Treated as a Checkbox
The vendor says the product “integrates” without understanding the systems, data flows, standards, and workflow requirements involved.
Required Data Is Harder to Access Than Expected
The solution depends on information that may not be available in the required format, frequency, or workflow.
Policy Changes Alter the Buying Conversation
New requirements or guidance affect how the provider evaluates risk, implementation, or future viability.
The Product Roadmap Trails the Market
Standards continue to evolve, but the vendor has not planned how the product will adapt.
Compliance Questions Arrive Late
The commercial team encounters privacy, documentation, information-sharing, or governance requirements after the opportunity has advanced.
Implementation Burden Expands
What appeared to be a straightforward deployment becomes a much larger integration and operational project.
A technically possible integration is not automatically a commercially practical integration.
Provider Perspective
Steve Posnack
U.S. Department of Health and Human Services / Office of the National Coordinator for Health IT
Ram D. Sriram
National Institute of Standards and Technology
Steve Posnack
U.S. Department of Health and Human Services / Office of the National Coordinator for Health IT
Understand the Policy Plumbing
Health IT companies often experience policy and interoperability requirements as individual technical requests.
Providers experience them as part of a much larger environment governing how health information is accessed, exchanged, and used.
Frameworks and standards such as FHIR, USCDI, TEFCA, and information-blocking requirements influence the expectations surrounding healthcare data exchange and increasingly shape what providers expect technology vendors to understand.
The commercial implication is that vendors do not need to become policy organizations—but they do need enough awareness to understand how the policy environment affects their product and their customers.
The GTM implication
Do not wait for the provider to explain the healthcare policy and interoperability environment your product must operate within.
Ram D. Sriram
National Institute of Standards and Technology
Standards Create a Common Language for Trust
Standards become particularly important as technology grows more complex.
For emerging areas such as AI, measurement, testing, uncertainty, and risk frameworks help organizations evaluate technologies more consistently and understand what evidence can—and cannot—support confidence.
Vendors that understand the standards and measurement environment surrounding their technology are better prepared to explain how performance, limitations, and risk should be evaluated.
The GTM implication
Standards are not simply technical requirements. They help providers determine whether claims about performance and risk can be trusted.
How to Diagnose Policy, Standards & Interoperability Readiness
Know the Ecosystem Your Product Must Enter
A Health IT company should understand the major systems and data relationships surrounding its product.
That may include:
- EHR platforms;
- clinical systems;
- operational systems;
- identity and access systems;
- data warehouses;
- APIs;
- health information exchanges;
- analytics environments;
- and third-party applications.
The question is not simply whether integration is technically possible.
It is whether the solution can fit into that ecosystem without creating disproportionate cost, complexity, or operational burden.
*LESSONS FROM THE FIELD: Reduce the Provider’s Integration Lift*
Technical lift can become a major barrier even when the buyer likes the solution. In one example, a key stakeholder would not move forward until we proved the required EHR data could be extracted. A data analyst tested our lightweight JavaScript utility and, within about 15 minutes, confirmed we had captured approximately 97% of the required data.
Reducing the provider’s technical lift can be just as important as proving the technology itself.
*LESSONS FROM THE FIELD: Start With the Integration You Need*
Our preferred long-term solution was a full interface, but requiring that upfront would have slowed the sale and increased the provider’s implementation burden. We used the lighter-weight data extract to get the customer operational, then worked toward the full interface after contracting.
The technically ideal integration path and the commercially practical integration path are not always the same on Day One.
The best integration strategy is not always the most technically complete on Day One. It is the one that reduces provider lift, proves feasibility, and creates a practical path to scale.
Understand the Standards That Affect the Use Case
Different Health IT products may encounter different interoperability and data requirements.
Relevant considerations may include:
- FHIR;
- USCDI;
- terminology standards;
- API requirements;
- data provenance;
- identity;
- security;
- information-sharing expectations;
- and other standards applicable to the specific use case.
The sales team does not need to become deeply technical.
But it should know which requirements materially affect implementation and buying decisions.
Standards become a GTM issue when they determine how easily the provider can adopt the product.
Track Policy as a Commercial Variable
Policy can influence:
- what data can or must be exchanged;
- how providers evaluate compliance;
- reimbursement;
- reporting requirements;
- governance;
- documentation;
- AI oversight;
- and future technology priorities.
That means product and commercial leadership should have a disciplined way to identify changes that could affect market demand or buying requirements.
A policy shift may create opportunity.
It may create risk.
Or it may change the provider’s definition of readiness.
Policy should not be treated only as a compliance issue. It can change the commercial environment around the product.
Design for Change, Not Just Today’s Requirements
Healthcare standards and policy continue to evolve and may vary by facility.
A solution designed only around the requirements that exist today may become difficult to maintain as those expectations change.
Providers may therefore evaluate:
- how adaptable the architecture is;
- whether standards updates can be supported;
- how quickly the vendor responds to change;
- whether integrations are overly customized;
- and whether the roadmap anticipates evolving requirements.
The provider is not only buying what the product can do today. It is taking a position on whether the vendor can keep pace with tomorrow.
Diagnostic Content — Bottom Line
Policy, standards, and interoperability readiness means understanding the ecosystem surrounding the product well enough to anticipate how data, integration, regulation, and evolving requirements could affect adoption and scale.
Better Discovery Questions — Don’t Ask / Ask Instead
Good interoperability discovery goes beyond asking what EHR the provider uses. It helps the commercial team understand the data, systems, standards, and policy requirements that could determine whether implementation is practical.
DON’T ASK
“Which EHR are you on?”
ASK INSTEAD
“Which systems, data flows, and workflows would our solution need to interact with in order to operate successfully?”
DON’T ASK
“Do you support FHIR?”
ASK INSTEAD
“Which interoperability standards and data requirements will your organization expect this solution to support for this use case?”
DON’T ASK
“Can your IT team handle the integration?”
ASK INSTEAD
“What integration effort, internal resources, and technical dependencies would your organization need to account for before moving forward?”
The objective is not simply to prove that integration is possible. It is to understand whether integration is practical for the provider.
From Product Compatibility to Commercial Readiness
Before treating technical capability as evidence of commercial readiness, the sales team should understand the systems, standards, data requirements, policy considerations, and integration effort that will determine whether the provider can realistically adopt the solution. The Buyer’s-Lens Test helps distinguish technical possibility from ecosystem readiness.
1. Questions Health IT Companies Should Be Able to Answer
☐ Which provider systems must the solution interact with?
☐ What data is required?
☐ Where will that data come from?
☐ Which interoperability standards apply?
☐ What integration effort will be required?
☐ What internal provider resources will be needed?
☐ Which policy requirements affect the use case?
☐ Could regulatory or standards changes alter product requirements?
☐ How will standards updates be supported?
☐ Are integrations scalable or highly customized?
☐ What technical dependencies could create risk?
☐ Can the vendor explain how the product fits the provider’s broader ecosystem?
If the sales team understands the product but cannot explain how it fits the provider’s technical and policy environment, commercial readiness remains incomplete.
The Buyer’s-Lens Test
An ecosystem-ready opportunity should allow the provider and sales team to answer “yes” to each of the following:
✓ Yes, we understand where the solution fits.
The required systems, data, workflows, and technical relationships are visible.
✓ Yes, the interoperability requirements are understood.
The relevant standards and integration expectations have been identified.
✓ Yes, the implementation burden is realistic.
The organization understands the resources and dependencies required.
✓ Yes, policy considerations have been addressed.
Known regulatory, information-sharing, or governance requirements are visible.
✓ Yes, the vendor can adapt as requirements evolve.
The product and company demonstrate the ability to respond to changes in standards, policy, and technology.
When those five answers are present, the provider is not simply evaluating whether the product works. It is evaluating whether the product belongs in its ecosystem.
David's GTM Takeaway
Health IT companies sometimes treat interoperability, policy, and standards as subjects for the product or technical team.
They certainly are.
But they are also commercial issues.
They affect implementation effort.
They influence provider risk.
They shape evidence requirements.
They can change the buying process.
And they may determine whether a promising solution can move from an interesting technology to something a provider can realistically adopt and scale.
Know the environment.
Understand the standards that matter.
Stay close to policy changes that affect the use case.
And do not wait until implementation to discover how difficult the technology will be to fit into the provider ecosystem.
In Health IT, the environment around the product can be just as important as the product itself.