Not to derail to an unrelated complaint about Fi, but it's absolutely wild that if you want to do a 3-way call from your Google Pixel phone using Google Fi service, you can't do it from WiFi (or rather, if you don't turn off WiFi before you start the call, then you'll be muted).
Apparently it's a sort-of-known issue, the workaround is to turn off WiFi before starting your call (wtf?) or use another carrier.
Active Frequency | activefrequency.com | Boston (REMOTE)
We're a custom dev agency, specializing (but not exclusively) in Django. We work with a diverse roster of interesting clients, across different industries (everything from healthcare to rock'n'roll).
We've been in business for 12 years, and the company is profitable. We're currently three full-time developers, looking to add an additional developer and our first in-house full time designer to the crew.
Taking that at face value, I'd say that "limit drivers doing it 'for fun' in exchange for better pay/protections for drivers doing it to eke out a living" seems like a reasonable trade-off...
No individual has any right to make a living doing anything they want to. If sufficient people are willing to do a job at a reduced wage because they enjoy it, that is their right.
This is like saying that libraries should ban unpaid volunteers in order to justify the hiring of more librarians.
It is illegal in the US to have volunteers do work that would otherwise be done by a paid employee. That's why unpaid internships are, by default, illegal - to be legal they must replace the payment with school credit and valuable experience, basically.
Labour laws set minimum standards that all companies and employees / contractors / whatever should adhere to, because it reduces the likelihood of abuse.
The "right" you mention doesn't exist in e.g. countries with minimum wage laws.
It gets into some (though hardly all) of the issues of why EHR software is the way it is, and why (some) doctors hate it. (Among my friends who are doctors, some hate Epic, and some absolutely love it - depends on specialty, age, institution, how it's configured, etc.)
Among some interesting issues:
- As others in this thread have noted, the buyer (administrator concerned with maximizing billing) is not the user. That's the easy one that's common to a lot of enterprises.
- Epic makes it easier for medical directors to track population health and impose standard protocols of care. Individual practitioners don't always like that! I am not expert enough in those fields to say who's right, and I suspect there's not always an obviously correct answer.
- A lot of doctors dislike the underlying mechanic - being forced to actually write down everything they're doing and why - on top of sub-par UIs. The goals of the system conflict with the goals of the practitioner.
- Interoperability sucks, but it's true that standards aren't really there, and it's hard to get consensus... plus everything you put in prod needs to be back-compatible approximately forever. A lot of institutions got burned by maintaining internal software built over decades that you can't turn off because lives depend on it, and Epic/etc. are part of trying to avoid repeating that mistake.
There's more. I only have a toehold in that world now, but love to chat about it. Email in profile.
The interoperability standards are actually pretty much there, at least for the more common types of patient records. The situation has improved tremendously in just the past few years. Epic and their major competitors are doing a decent job of supporting the lastest HL7 CDA and FHIR standards, including specific implementation guides.
The bigger problem now is that many provider organizations haven't upgraded to current EHR release versions, or haven't opened up their systems to access by other providers.
> - Epic makes it easier for medical directors to track population health and impose standard protocols of care. Individual practitioners don't always like that! I am not expert enough in those fields to say who's right, and I suspect there's not always an obviously correct answer.
This is more complex than it looks. Picture this: "I only have 12 minutes to spend with this patient, the initiative wants me to spend 7 minutes talking about things x,y, and z but the patient has come in with an urgent pain and rash that have nothing to do with x, y, and z. I must fail on this initiative in order to do what the patient has actually come to me for."
There are a lot of things that intersect here. One is creating initiatives that really belong to public health and creating an unfunded mandate to make healthcare organizations provide that (e.g., active outreach to get people to come in and get their flu shots). No specialist in X - whether it be tech or healthcare - wants to get tangential work piled on them that has nothing to do with their actual work, and not get paid for it to boot. But if you don't do it, your reimbursement gets dinged. Essentially all healthcare policy in the US is built around sticks, not carrots: do X or we will withhold your pay.
Two, is that these initiatives often diverge from what the patient wants. A patient comes in for an acute rash and pain, and they really don't want you using up the time you need to examine them to discuss something else. "What about general check-ups?" One of the discoveries early on in the ACO program roll-out was that regulations built on the assumption that patients had annual check-ups went belly-up. Patients tend to go to their doctor a lot less often than that. Many people only go once every 18-24 months - too infrequently to pass the standards the government is imposing.
Three, the system as it stands only funds brief visits, often inadequate to properly taking care of patients.
Four, all of these things have to be documented in a very rigid way, to ensure that the EMR can ultimately be used to upload the results to the government or insurer so that they can assess how you did.
Five, the EMR strong-arms you into doing these things, jumping through a bunch of bad UI along the way. If it's inappropriate to provide, you still have to do a bunch of mandatory paperwork, because ... well, the EMR is really trying to strong-arm you.
All of these issues compound and intersect. The EMR is there to force you to do the thing that isn't yours to do and that the patient doesn't want and you have to choose between that and what they want because the funding is built around visits too brief to do both.
But, isn't it good to try and get docs to actually give everyone flu shots? Yes it is. I used to administer one of these programs, and I assure you, doctors' perception of how thoroughly they provide preventive care is wildly divergent from how thoroughly they actually do it. But instead of offering a carrot, we've created a stick, and system to apply it to the bottom of doctors' feet.
> - A lot of doctors dislike the underlying mechanic - being forced to actually write down everything they're doing and why - on top of sub-par UIs. The goals of the system conflict with the goals of the practitioner.
That's not the problem. The problem is that the reimbursement agency - be it CMS or an insurer - wants things documented in a very particular, rigid way that requires a shit-ton of boxes to be clicked and fields to be filled out, so that every little task becomes magnified by an order of magnitude.
Teaching docs to link together assessment + plan wasn't very difficult. Convincing them to fill out a form every time they don't give a hypertensive an ACE/ARB is more of a pain in the ass ("Because this guy's going to be dead in three to six months, so the monetary cost and potential side-effects aren't offset by any clinical gains whatso-fucking-ever" is annoying to repeatedly fill out. Or more realistically, "because he's telling me his urine output in response to his diuretics is going down and I'm concerned we're boxing his kidneys, so maybe I'll give him an anti-hypertensive that doesn't directly beat on his kidneys... even though his creatinine hasn't jumped yet, so I have no actual evidence to present to the government/insurer to support this, so it looks like I'm just ignoring standards willy-nilly.")
To some degree, yes - Massachusetts did that, in fact, and the plan there (that was signed, somewhat ironically, by Mitt Romney) is very very similar to the ACA.
There are a lot of details, though, that make this complicated and not necessarily viable for all states (MA is both relatively wealthy, has relatively wealthy neighboring states, and has a somewhat unusual healthcare market).
Here's a common scenario: you maintain more than one project, and you can't just simultaneously upgrade e.g. Django for all of them (or literally any library where an upgrade may be non-trivial).
Yes, eventually you'll (hopefully) upgrade all your projects to the newest and shiniest versions of all your dependencies, but if you need to maintain some semblance of stability, that's not always immediately possible/practical.
I'd rather use docker over venv in that case. My host python is for horsing around, when something is to be deployed I document and isolate the dependencies in a dockerfile. venv would only solve half that problem and only for python, not including outside delendencies.
If the solution to packaging is "I'll use docker", i.e. I will need essentially an entire OS as a dependency of my application, this shows that Python packaging is broken. More sane packaging system allow to define dependencies per project, and only install packages globally when required
True. I also work in a HPC context where that's a problem. That's actually a place where I had to hack together something with venv in order to use an output analysis with a python that's compiled differently from the main Fortran executable. But that's quite an edge case.
In general if a tool requires root to run, of course a system administrator could make some changes to the system to allow a user to run it (adding the user to a privileged group, making the binary setuid, etc).
But that's not the point. The point is, if I'm on a system where I don't have the ability to make system-wide changes (run docker as root, add myself to a special group, etc), then I can't run docker on that system.
