Hacker News Reader

Comment by josephpmay | Hacker News Reader

That’s just completely untrue. First of all, Epic has a built in tool called Slicer Dicer for clinicians to perform pretty complex population data analysis without having to do any database queries. Second, every healthcare organization extracts much of their patient data to a data warehouse where you can perform direct SQL calls on it.

View on HN

MD here too. I encourage you to stop and think about your defensive reaction to a tool you know well that's designed for exactly the purpose the client is looking for. OP, who I wager uses Epic every weekday for 5+ hours, has no idea about this tool and probably wishes existed (I'm guessing). It's probably not included in their software contract, or there are unnecessary HIPAA issues, or the IT person is not competent. Just some of the many issues.

On the radiology side, I know there are extensions and tools for PACS that the vendors can't be bothered to come explain/train, even though the company sold it to the hospital. It's like pulling teeth.

Valid point. My defensiveness was less directed towards OP's specific scenario but rather to the blanket statement that EHRs are broken in this way, when there are specific and high-quality tools designed specifically for data analysis. A lot of people, including myself, tend to put a lot of faith in HN comments about industries that we are not personally familiar with, and someone reading OP's comment would likely get the wrong impression about the state of the medical records industry.

There are certainly a million reasons why a doctor may not have access to or be able to use tools like Slicer Dicer, but most of those come down mainly to hospital policy. Amount and quality of training is certainly the biggest differentiation between clinician who are satisfied with Epic and those that hate it.

You are correct, I made a blanket statement based on what was apparently incorrect information. But, I'm glad I made it on HN, because I went from having an incorrect assumption to having a solution!

So, thank you!

Thank you very much for sharing that. I'll look into it more. The clinicians (head of trauma Evidence-Based Medicine as well as the head of the trauma department overall) I have talked to at my non-academic Level II trauma center do not have any clue this exists. They are currently exporting thousands of records by hand.

Edit: Do you know offhand of a good guide to SlicerDicer I can share with them? I will google around, but if you had something you personally liked?

There's still likely some good reason to do that work manually. The quality of data entry into EMRs is often poor, especially when it comes to event or time data that's not just numeric bloodwork. Imagine that at a random physicals date your patient was suddenly was 155kg and 65cm tall. Or for another example, having someone be inaccurately be diagnosed as having new onset diabetes after transplant, despite them having DM for several years prior. People switch up entry fields, inaccurately assess or diagnose patients all the time--generally because of the sheer variety of ways in which data can be screwed up, only a person can notice those oddities (or write a little script to fix them).

At population levels I could concede that these errors may well be inconsequential though.

I work at Epic, so the resources I have are all internal training/document. That being said, the best way to learn it is probably to have someone who’s an expert in it, ideally another doctor, walk them through it. If you want, I can see if I can find some specific customer-facing documents/training to link them to.

Lack of public documentation has to be my #1 pain point with proprietary software over the years.

Especially in the EMR space, putting up barriers to access basic documentation is quite unreasonable.

Public documentation is not going to suddenly allow your competition to gain an advantage, while your own firm benefits from users being able to easily google and get authoritative answers from your own official documentation.

Reply on news.ycombinator.com