171–180 of 259 posts
Smart choice, considering the shutdown of GCE in 2023.
Are you being sarcastic?
The dementi was overspecific. "We did not discuss this in 2018". Which could mean they discussed it in 2019 or 2017.
Earlier quoted context omitted.
I try hard not to give my data to Google, for a lot of reasons. As a patient, having my healthcare provider hand my data over for them to monetize in God-knows-what ways is...undesirable.
This is where things get mixed up. EPIC is suggesting that using Google Cloud is somehow equivalent with handing data over to Google so that Google works with that data. These are absolutely, extremely different. Assuming that Google will somehow break into your VMs or GKE clusters to get data out and monetize it is crazy, of course, but EPIC tries to suggest that.
All these things taken together means it is not crazy to imagine that this is the case. If it is not the case currently, we have to assume it will be the case soon and that when it does become the case, historic data is still available. They are therefore always a bad choice.
Earlier quoted context omitted.
I talked to a doctor at Stanford and he mentioned to me one reason why the main Stanford Health and Stanford Children's Health have separate patient portals (not unified) that you have to create separate logins for is because of the huge amount Epic wanted to charge to merge them. (They both run separate Epic instances as far as I can tell)
How are leeches like this tolerated? The sooner they are driven out of business, the better.
Earlier quoted context omitted.
How are leeches like this tolerated? The sooner they are driven out of business, the better.
They're not entirely tolerated fortunately. The US government has been taking action to tear down EHR walled gardens via the Cures Act[1] which is manifesting in public access APIs called FHIR. [1] https://en.wikipedia.org/wiki/21st_Century_Cures_Act
The situation is sort of like moving from SOAP+XML Schemas to REST/JSON. Easier to develop, but the underlying data structures are still extremely complicated and tricky to get right.
This is especially true when dealing with ancient systems written in niche languages/database hybrids (MUMPS comes to mind): https://en.m.wikipedia.org/wiki/MUMPS
Earlier quoted context omitted.
It depends on the setting. In a hospital (or hospital-owned primary care), the EMR generally reflects the top heavy administration. You end up with a billing system masquerading as an EHR. In an independent practice, there are more options, and some are quite good (I work for one that I happen to think is pretty great in that regard, and most of our users seem to agree)
eClinical?
Earlier quoted context omitted.
You’ve just described Jira, or really any other heavily customisable tool that can fit multiple complex workflows.
Having used a dozen EMR systems and Jira, I'd say Jira is much better at its job than most EMRs are at theirs. In fact, now that you mention it: you could easily model each patient as an epic, assignments to various people on various teams (ICU, pharmacy, lab, etc), to-do/in-progress/done. Holy cricky, you may have just cracked the EMR nut.
Earlier quoted context omitted.
I highly doubt this. A company of that size with separate P&L division (ex. GCP), operate like collection of mini companies. Executive of one 'mini company' is free to take their own decision which is good for their division and their OKR.
I doubt that the data flow will be contained within these "mini companies". Formally they are the same company and even with the inefficiency of large corps, I doubt that Google doesn't have the capabilities to efficiently exchange information. That aside, I do not want to rely on the inefficiency of internal processes for data protection.
Google is absolutely doing the right thing. Anything that can be done to enhance the efficacy of EMR software will help lead to better patient outcomes. As far as I can tell, Google is approaching the problem foremost from the perspective of "how can we make people healthier by making software more effective." Epic and Cerner are simply not doing that. Somewhere in the comments here someone mentioned that most EMR so…
> The software is designed to be sold to administrators and, as currently designed is unquestionably leading to worse outcomes for patients.
disclaimer: I’m a former Epic employee who worked on their inpatient app.
Do you have data or literature to support these statements for a typical Epic implementation or is this just anecdotal and biased?
Although there were ALWAYS some sort of issues and pushback from clinicians during implementation and go live, Epic software and data flow literally revolves around patient care and not billing. I don’t recall exactly which apps came first when Epic was born in the 1970s, but I believe their billing and admin apps came much later than many of the clinical apps. It’s actually why they still use a backend on top of mumps and cache, because the way data is stored and flows in these systems can do so literally around the core patient data structure, which should theoretically make a clinicians job easier to review a complete patient record (not make it easier for billing).
Google is absolutely doing the right thing. Anything that can be done to enhance the efficacy of EMR software will help lead to better patient outcomes. As far as I can tell, Google is approaching the problem foremost from the perspective of "how can we make people healthier by making software more effective." Epic and Cerner are simply not doing that. Somewhere in the comments here someone mentioned that most EMR so…
Google is absolutely doing the right thing. Anything that can be done to enhance the efficacy of EMR software will help lead to better patient outcomes. As far as I can tell, Google is approaching the problem foremost from the perspective of "how can we make people healthier by making software more effective." Epic and Cerner are simply not doing that. Somewhere in the comments here someone mentioned that most EMR so…
> In most implementations, neither Cerner not Epic encourage structured data recording except for billing codes. > The software is designed to be sold to administrators and, as currently designed is unquestionably leading to worse outcomes for patients. disclaimer: I’m a former Epic employee who worked on their inpatient app. Do you have data or literature to support these statements for a typical Epic implementation…