Hacker News Reader

Comment by specialist | Hacker News Reader

What you say is true. I solved the problem by flipping it around.

I'm going to give away the secret sauce I created for our backend.

"Traditional" EMRs imagine an idealized data model and then write ETLs to import to that model. The jargon we used was "adjudicating the single best record (SBR)" or "source of truth".

My system slurped up all data, stored mostly as-is, and then used information retrieval strategies (think Lucene) instead of querying (think SQL).

This solution was wicked fast. We showed our customers data back to them, so validation was simple. And we were super nimble when they changed their minds (what is a "visitation", how to displays scripts, updating lab results).

Sad story short: our group was acquired, my strategy made the reigning CTO's head explode, he attempted a rewrite, failed, then the execs killed the product.

View on HN

Better search is definitely needed and seems like something the EPICs and Cerners of the world could easily do if they just assigned a couple smart people and left them alone. Instead they'll probably form vast teams of search stakeholders.

But search is only one need. You say EMRs imagine an idealized model. Maybe. They certainly never develop one. And that's what you need to reach the potential of medical data analytics. The software needs to "understand" what the data means without constant human intervention

Perhaps my effort was informed by my prior experiences with ERP/CRM systems and the semantic web.

I'm firmly in the folksonomy (vs taxonomy) camp.

We just showed our customers data back to them. In most cases, it was the first time they'd ever seen it. Hence the churn on "what is a visit", resolving scripts, etc.

I don't know anything about medical data analytics, but if we captured the data, then its there to be mined. It was just HL7 (or whatever), as is.

Honest question: who wants to read raw HL7? To whom is the ability to access HL7 on-demand a killer feature?

Out of curiosity, what kind of data do you propose searching? Do you mean searching a patient chart? Searching for lab results? Searching doctor notes? Or do you mean more like analytics to see trends? Or for finding patients, in the vein of an national patient ID service?

I ask because there is some amount of chart searching and organization analytics in the big EHR products so I'm curious which part you think is specifically lacking?

The "and left them alone" is a very important point that is not being met for innovation.

Did you ever make it to a 510(k)? I can see Lucene making their head explode too...to say nothing of validation without checks on overwriting patient info, etc

I plead ignorance about 510(k). Scanning the wikipedia article, it might have come into play if our "patient portal" (think Microsoft HealthVault, Google Health) ever got traction. Because our brilliant notion was to store patient collected data (heart, glucose), to be shared with care providers. Another complete non-starter.

We did have live data feeds to the CDC. If there was a hoop, I assume we jumped thru it.

validation without checks on overwriting patient info

Our data store was write-only. In SQL parlance, no UPDATEs, just INSERTs (and SELECTs).

One hard requirement was to be able to show what was known when about a patient. "Traditional" data store solutions have "live" tables, separate history tables (recording changes), and maybe audit logs. My solution just had the log. Queries used a date range. Made QA/test trivial.

Reply on news.ycombinator.com