6 ms·

It's among the least bad, but nobody would ever mistake it for software sold to general consumers in this century. I know it's complex and specialized, but so a

It's among the least bad, but nobody would ever mistake it for software sold to general consumers in this century. I know it's complex and specialized, but so are IDEs, and those are (in my limited use and understanding of them) worlds better in their engineering. That said, I'm not crazy about how actively Epic appears have tried to keep medical records created in Epic locked in to Epic. The spirit, if not the letter, of the legislation requiring a move to electronic records was due to record portability. From where I stand, they have actively prevented that (or at a very minimum sandbagged) to expand their market share.

phobosanomaly 6y ago
Another unintended consequence of this is that it makes it extremely difficult for doctors and nurses to pull data to do basic research or look at patient outcomes. For example, if you wanted to see what the outcomes of giving a specific drug at a specific dose to a specific group of patients at your hospital was, you're in for a real fun time manually copy-and-pasting thousands of entries from the EMR to a spreadsheet. Now more than ever it is important to look at data relating to patient outcomes with various COVID treatments that haven't been thoroughly vetted yet. But, guess why your local hospital isn't doing anything like that? Because what should be a simple 3-hour exploratory data analysis that can be breezed through IRB now has to involve a budget component of hiring a professional copy-paste person. Can't even use med students to do it anymore because they aren't allowed to hang around the hospital due to COVID, and you can't access those records remote due to HIPAA.
- josephpmay 6y ago
  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.
  - phobosanomaly 6y ago
    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?
    - josephpmay 6y ago
      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.
      - owowow 6y ago
        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.
      - deleted 6y ago
        [deleted]
    - thesishelp 6y ago
      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.
- willcipriano 6y ago
  > and you can't access those records remote due to HIPAA. The person who told you that is misinformed. I have personally worked on products that allow physicians and staff to access patient records remotely in a safe and fully HIPAA compliant manner. It's incredibly common.
  - phobosanomaly 6y ago
    Sorry, I worded that poorly. I meant the med students doing the grunt work.
- nradov 6y ago
  Most EHRs now have standard HL7 FHIR APIs which would allow remotely querying that data.
  - phobosanomaly 6y ago
    Thanks for the heads-up! Do you know of a good way to leverage this API in a way that can be directly used by clinicians to pull and work with data?
    - nradov 6y ago
      You'll have to start by finding the FHIR web service endpoint URL for your EHR instance, as well as appropriate authentication credentials. Client applications can be written using the HAPI FHIR library. https://hapifhir.io/ https://hapifhir.io/ Then use the search operation to find the resources you need. http://www.hl7.org/fhir/search.html http://www.hl7.org/fhir/search.html
nimish 6y ago
Thankfully, TEFCA was implemented anyway, and is still on schedule. We'll see what it works out to in practice. But data sharing is definitely still possible, today, even with Epic (they are quite good actually). You are limited to certain reasons but they are pretty broad. Full disclosure: I work on this full time. It is a strange world, that works on its own standards and practices for good and bad reasons.
nradov 6y ago
The latest version of Epic has fairly complete record portability. Is it missing anything specific? https://open.epic.com/ https://open.epic.com/ I think EHR vendors sometimes get unfairly blamed. The fault often lies with provider organizations who simply haven't turned on the available functionality.
- odyssey7 6y ago
  Why do I feel stressed out visiting this link on desktop? Perhaps someone who's good at UX could share a few thoughts?
  - hanklazard 6y ago
    Ha, exactly. UI/UX is precisely the area where Epic fails the most. I am not an expert in this area, but in my every day use, I can only describe the Epic style of UX as "vomit all information onto the screen at once."
    - nradov 6y ago
      Given a choice, clinicians would usually rather have maximum information density to avoid clicking around for what they need.
      - Shared404 6y ago
        Some better organization to the information would be nice though. Edit: Not a doctor/in health care. Just basing this on the link above.
        nradov 6y ago
        Better how?
        Shared404 6y ago
        Looking at the website right now, I see three different horizontal arrangements of links. Of these links, there are four duplicate pairs, at least. Two of these sets of pairs lead to indistinctly named pages (/Home/InteroperabilityGuide and /Home/Interoperate) I would start by having all of these links be at the top, and adding some descriptive text to each of the fields in the main body, as opposed to meaningless graphics/marketing numbers. Addendum: Also, I wouldn't want to do the split in thirds thing that occupies the majority of the page. Each of those can get a description of at least a paragraph, and go one after the other. If there's not enough info to fill a paragraph, then they probably need to be merged. Edit: ambiguously -> indistinctly

phobosanomaly 6y ago

Another unintended consequence of this is that it makes it extremely difficult for doctors and nurses to pull data to do basic research or look at patient outcomes. For example, if you wanted to see what the outcomes of giving a specific drug at a specific dose to a specific group of patients at your hospital was, you're in for a real fun time manually copy-and-pasting thousands of entries from the EMR to a spreadsheet. Now more than ever it is important to look at data relating to patient outcomes with various COVID treatments that haven't been thoroughly vetted yet. But, guess why your local hospital isn't doing anything like that? Because what should be a simple 3-hour exploratory data analysis that can be breezed through IRB now has to involve a budget component of hiring a professional copy-paste person. Can't even use med students to do it anymore because they aren't allowed to hang around the hospital due to COVID, and you can't access those records remote due to HIPAA.

josephpmay 6y ago
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.
- phobosanomaly 6y ago
  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?
  - josephpmay 6y ago
    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.
    - owowow 6y ago
      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.
    - deleted 6y ago
      [deleted]
  - thesishelp 6y ago
    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.
willcipriano 6y ago
> and you can't access those records remote due to HIPAA. The person who told you that is misinformed. I have personally worked on products that allow physicians and staff to access patient records remotely in a safe and fully HIPAA compliant manner. It's incredibly common.
- phobosanomaly 6y ago
  Sorry, I worded that poorly. I meant the med students doing the grunt work.
nradov 6y ago
Most EHRs now have standard HL7 FHIR APIs which would allow remotely querying that data.
- phobosanomaly 6y ago
  Thanks for the heads-up! Do you know of a good way to leverage this API in a way that can be directly used by clinicians to pull and work with data?
  - nradov 6y ago
    You'll have to start by finding the FHIR web service endpoint URL for your EHR instance, as well as appropriate authentication credentials. Client applications can be written using the HAPI FHIR library. https://hapifhir.io/ https://hapifhir.io/ Then use the search operation to find the resources you need. http://www.hl7.org/fhir/search.html http://www.hl7.org/fhir/search.html

nimish 6y ago

Thankfully, TEFCA was implemented anyway, and is still on schedule. We'll see what it works out to in practice. But data sharing is definitely still possible, today, even with Epic (they are quite good actually). You are limited to certain reasons but they are pretty broad. Full disclosure: I work on this full time. It is a strange world, that works on its own standards and practices for good and bad reasons.

nradov 6y ago

The latest version of Epic has fairly complete record portability. Is it missing anything specific? https://open.epic.com/ https://open.epic.com/ I think EHR vendors sometimes get unfairly blamed. The fault often lies with provider organizations who simply haven't turned on the available functionality.

odyssey7 6y ago
Why do I feel stressed out visiting this link on desktop? Perhaps someone who's good at UX could share a few thoughts?
- hanklazard 6y ago
  Ha, exactly. UI/UX is precisely the area where Epic fails the most. I am not an expert in this area, but in my every day use, I can only describe the Epic style of UX as "vomit all information onto the screen at once."
  - nradov 6y ago
    Given a choice, clinicians would usually rather have maximum information density to avoid clicking around for what they need.
    - Shared404 6y ago
      Some better organization to the information would be nice though. Edit: Not a doctor/in health care. Just basing this on the link above.
      - nradov 6y ago
        Better how?
        Shared404 6y ago
        Looking at the website right now, I see three different horizontal arrangements of links. Of these links, there are four duplicate pairs, at least. Two of these sets of pairs lead to indistinctly named pages (/Home/InteroperabilityGuide and /Home/Interoperate) I would start by having all of these links be at the top, and adding some descriptive text to each of the fields in the main body, as opposed to meaningless graphics/marketing numbers. Addendum: Also, I wouldn't want to do the split in thirds thing that occupies the majority of the page. Each of those can get a description of at least a paragraph, and go one after the other. If there's not enough info to fill a paragraph, then they probably need to be merged. Edit: ambiguously -> indistinctly