John Jones has been building the same regulatory data platform since the late '90s. The databases changed. The data model didn't. In this episode he explains why companies burn 18 months on plumbing before they ever get to governance, data quality, or compliance, and why he turned the DIA RIM Reference Model into a pre-built platform called Nidura so nobody has to do it again. Matt and John get into why canonical models get a bad name, why AI trips over the same things people trip over, what a real path to taking the human out of the loop looks like, and a side quest on tokens, gym memberships, and pickleball.
John Jones is the founder and creator of the Nidura platform. He is Chief Executive Officer of Entitech Solutions and SVP, Head of Life Sciences Consulting at Tandym Group. Earlier roles include Practice Lead for IT Strategy & Implementation at Quintiles, Vice President of Application & Integration Solutions at HighPoint Solutions, Solution Partner for Life Sciences at Business Edge Solutions, and IT Manager at Aventis Pharmaceuticals. He started out as a mechanical engineer at Ford Motor Company and holds a BS in Mechanical Engineering and an MBA from Rutgers. John spent a good five years working on the DIA RIM Reference Model alongside Bala Balasubramanian, Joel Finkle, and others. Find him on LinkedIn.
The model never changes. The plumbing always does. (1:49) John has built data platforms on SQL Server and Oracle, then Redshift and Azure, now Databricks and Snowflake. His observation: the technology keeps changing, but the data and the way the business transacts it do not. The time goes into mapping today's source system into the model, and governance, data quality, and compliance get dropped when that mapping gets hard. Nidura is his "easy button on the plumbing": standard data models at the core, a data mesh framework, and business-owned data products.
The RIM Reference Model as the foundation (5:56) Following Bala's visit in OU-007, John describes the working group spending an entire night on a single field because the field needed it. That work gave Nidura a model to make physical. He uses CDISC's USDM the same way for the clinical model. He notes the RIM Reference Model documentation is now publicly available on the DIA website.
Why canonical models get a bad name (8:06) John thinks people see the value. The problem is that the word "model" makes it sound like an IT-led initiative, the work gets stuck in technical analysis paralysis, and ambitious projects fizzle. His view is that it only works with business people driving.
AI stumbles where people stumble (11:56) Matt argues there's a false perception that AI will do everything without the plumbing. John agrees: poorly defined, poorly annotated data confuses AI the same way it confuses a person. Companies pull off a few use cases and end up with tooling overfit to one situation, something he saw in the vendor booths at DIA Global this year. He favors a context layer available to every prompt over prompt engineering for one question at a time.
Getting the human out of the loop (23:06) John compares it to trusting a new employee. Accuracy goes up when AI makes lots of little decisions on small, precise, well-annotated pieces of information. He suspects ever-larger context windows make people lazy, and points to structured content such as ePI-formatted labels and structured authoring as the path.
Side quest: tokens, gyms, and pickleball (26:01) Matt compares token pricing to old cell phone calling areas and pitches a flat gym-membership model. John thinks tokens are here for a while, that compute gains are flattening, and that token efficiency is the next wave. With AI built into everything, he expects pickleball, not the gym. Matt notes that PDF versus text changes the token count, and that the "new" advice to build folder hierarchies with MD files is the folder structure we already walked away from.
A second value prop, and the same old hurdles (38:10) Standard models used to be a reporting and analytics pitch. Now AI needs the same data, which opens up delegating work: generating documents from data, or checking documents against data so XEVMPD submissions match SmPCs. The hurdles haven't moved, though. People working on the data still need to understand it, and John says newer platforms let you house more data and get to it faster without solving that.
18 months versus a button press (44:55) John's estimate for building a regulatory data hub from nothing: a couple of months on a physical RIM Reference Model, six to eight months of ETL from Veeva, a couple more of testing, then six months of edge cases. Nidura pre-built that, and he says it happens in the first hour of operation.
What users get (46:36) Three things. Ask the data questions through an AI console, with your own model or one provided, and get answers in RIM Reference Model terms. Build reports and dashboards from data products the business controls, including who gets access, how (JDBC/ODBC, API, MCP, download), and row-level security. Feed other systems for integration. Consumers can raise issues back to the data owner, and owners can publish the quality criteria a data product is meeting.
"They're the first things to go out the window when the plumbing becomes difficult." (John, 1:49, on governance, quality, and compliance)
"We would spend an entire night talking about a field, right? Because it needed to be talked about." (John, 5:56)
"The model is just a way that the business transacts data... It's not a technical thing." (John, 8:06)
"It's really a peanut butter and jelly type situation." (John, 13:55, on the RIM Reference Model and language models)
"AI doesn't complain, but it complains in the form of wrong answers." (John, 17:16)
"The plumbing has to be there first to guide AI." (Matt, 9:35)
"I think it's going to create more of a pickleball style model than a gym membership." (John, 34:53)
"We're not in the age yet where the report is dead or the dashboard is dead." (John, 47:10)
"That's honestly what I've been building for the last 30 years. And I'm like, wow, I'm building the same thing over and over again." (John, 52:01)
Regulatory operations and RIM leaders who are tired of funding the same data hub twice. Regulatory data folks working with the RIM Reference Model. IT and data teams building regulatory data products on Databricks or Snowflake. Anyone being asked to "just put AI on it" before the data is defined.
Guest and platform: John Jones on LinkedIn.
DIA RIM Reference Model: V2.0 User Guide. DIA Global Forum overview. RSIDM 2025 session on V2.0, where John presented the deep dive.
Standards mentioned: CDISC USDM. EMA electronic product information (ePI). EMA XEVMPD.
Technology mentioned: Veeva RIM. Databricks. Snowflake. Copilot.