This interview is with Noah Gula, AVP at OSP, OSP.
For Connectively readers, could you introduce yourself—what you lead as AVP at OSP and where your work sits at the intersection of custom software and healthcare?
As AVP at OSP, I help lead health tech initiatives at the intersection of business strategy, solution design, and delivery. I sit where healthcare organizations’ toughest operational problems live, such as EHR integration and interoperability, revenue cycle management, virtual care, automation, and AI. These are the systems that determine whether care is delivered on time, whether claims get paid, and whether clinicians spend their day treating patients or fighting software.
My role goes beyond building software; it’s about ensuring the right technology is built, integrated, and adopted successfully. I spend a lot of time at the intersection of technical architecture and the operational, financial, and clinical realities that determine whether a solution will actually work in a live healthcare environment.
How did your path to AVP at OSP shape the way you approach building and scaling tech solutions in healthcare today?
It changed my perspective from seeing health tech primarily as a software challenge to seeing it as a workflow challenge.
Writing the code is often the more straightforward part. Understanding how that technology affects a clinical shift, how it fits into an existing workflow, how it integrates with legacy systems, and whether it meets privacy and compliance requirements is where solutions succeed or fail.
For me, scalable healthcare technology requires sound architecture, engineers who understand the healthcare context, and continuous validation with the people who will actually use the product.
A technically impressive solution that adds unnecessary clicks or creates another workflow for clinicians to manage has missed the point. Usability, interoperability, and compliance have to be designed in from the beginning.
From your recent work, what is one custom healthcare solution from OSP you’re most proud of, and which single design decision most moved the needle on outcomes?
One solution I’m particularly proud of was an integrated healthcare workflow platform that connected fragmented front- and back-office systems and reduced duplicate data entry and manual handoffs.
The single design decision that made the biggest difference was keeping the workflow inside the EHR wherever possible, rather than introducing another standalone tool.
That reduced context switching for staff and made adoption much easier. It reinforced the principle that the best healthcare technology should simplify the workflow, a principle OSP believes.
When evaluating advanced tech like AI, RPA, or IoMT versus a simpler build, what practical go/no-go rule do you use that teams can apply before writing code?
If a problem can be solved reliably with a clear rule and a checklist, I would not start with AI.
Advanced technology makes sense when there is genuine variability, ambiguous input, complex decision-making, large volumes of unstructured information, or patterns that change over time. More predictable processes are often better served by deterministic automation.
That approach is usually easier to build, audit, maintain, and govern.
One of the most useful questions a team can ask before adopting AI is:
“Does this problem actually require intelligence, or does it require better automation?”
Using AI where a simpler solution will work often adds cost and complexity without adding meaningful value.
Once you’ve chosen the approach, what repeatable steps do you take to de-risk interoperability—FHIR/HL7 and EHR integration—so go-live doesn’t disrupt clinical workflows?
We generally focus on three things.
-
Map the data flow before building the integration. We identify where the data originates, where it needs to go, how fields and events are interpreted by each system, and where failures or mismatches could occur.
-
Test with realistic data early. Integration testing should reflect real clinical scenarios and edge cases. That validation should happen throughout development rather than immediately before go-live.
-
Design for failure. Every critical interface needs a recovery path. If an integration fails in the middle of a clinical or operational workflow, staff need to know what happens next without waiting for an emergency intervention from IT.
In my experience, interoperability problems are often less about FHIR or HL7 themselves and more about assumptions around data, workflows, and system behavior that were never tested.
On the talent side, how do you structure and coach cross-functional teams at OSP so engineers internalize healthcare domain constraints and ship safer solutions faster?
We try to bring engineering, product, healthcare domain expertise, and quality considerations into the same conversation as early as possible.
Healthcare context cannot be something engineers discover after development is already underway. Teams need to understand the workflow behind the requirement.
That means discussing real-world use cases during planning and design reviews, validating assumptions with domain experts, and bringing end-user feedback back into the development cycle through UAT and iterative releases.
I encourage engineers to ask a simple question before implementing a requirement: “What happens to the person using this if our assumption is wrong?”
That mindset changes the quality of the solution. It moves the team from simply delivering functionality to thinking about safety, usability, operational impact, and unintended consequences.
Given your views on platform sprawl, what is your first-90-days plan inside a health system to consolidate overlapping tools while preserving a clear system of record?
I would break the first 90 days into three phases, with one rule throughout: understand actual usage before removing anything.
-
During the first 30 days, I would map the technology landscape — what tools are in use, who uses them, what workflows they support, what data they own, and which unofficial workarounds have developed around them.
-
Between days 30 and 60, the focus shifts to defining the true system of record and identifying genuine redundancy. Two tools may appear to serve the same purpose on paper but support very different frontline workflows in practice.
-
By day 90, I would establish a phased consolidation roadmap with clear ownership, data boundaries, migration requirements, and sunset criteria.
The key is avoiding abrupt changes that disrupt clinical or operational workflows. Tool consolidation is as much a change management exercise as a technical one. If users lose a capability they depend on, with no workable replacement, shadow IT comes back.
As you bring AI into HIPAA-regulated environments, how do you operationalize governance so models are monitored, auditable, and trusted by clinical leadership?
AI governance cannot be a one-time approval before launch. It has to become an operating discipline.
-
Data minimization: In HIPAA-regulated environments, I start with data minimization. The system should have access to the information required for the specific use case.
-
Traceability: When AI supports documentation, clinical review, revenue cycle, or other sensitive workflows, the organization should be able to understand what the model produced, what information informed the output, and what happened afterward.
-
Human review: For higher-impact decisions, there needs to be a clearly defined human review point.
-
Ownership: Someone has to be accountable for monitoring quality, reviewing exceptions, watching for performance changes or drift, and determining when the system needs intervention.
Looking ahead two to three years, what is one underappreciated opportunity in healthcare technology that leaders should act on now to drive meaningful patient or operational impact?
The biggest underappreciated opportunity is to do the foundational data and interoperability work now.
The industry is understandably focused on advanced AI applications, but AI is only as useful as the data and workflows that underlie it.
Health systems should be asking whether their data are consistent, accessible, governed, and reliable across systems. They should be looking at integration architecture, identity, terminology, data quality, and the reliability of the pipelines feeding downstream applications.
Organizations that strengthen those foundations now will be able to deploy new technologies faster and with much greater confidence over the next several years.
The competitive advantage will not necessarily belong to the organization with the most AI tools; it will belong to the organization with the cleanest path from data to decision.
Thanks for sharing your knowledge and expertise. Is there anything else you'd like to add?
One thing I’ve picked up in healthcare technology is that trust matters more than features.
Clinicians, staff, patients, and leadership need to know the technology will be reliable, secure, and fit naturally into their workflows.
AI and other technologies will continue to evolve, but that principle doesn’t change. At OSP, we focus on building solutions that work in real-world healthcare environments, reduce friction, and earn trust through consistent performance.