Opex is "better" than capex, because cash is king. Capex in general means you pay upfront and reap benefits later. Opex in general means you reap benefits now and pay later (via invoice or credit card bill).
A business can be EBITDA positive but cashflow negative, or vice versa. However healthly your margin is, it is game over if you are unable to service your debts (including employee salary) before you receive cash from customers/investors.
On the other hand, if you are operating at a loss, you will be able to continue doing so indefinitely via continuous cash infusion by investors (which might include the public in case of a public company)... until the cash does run out.
I don't understand. Artists can also use these models to generate art, and looking at other industries, there are significant differences between professional output and "machine generated" output. Sort of the difference between a fullstack developer and no-code platform. Do developers fear no-code platforms taking over their jobs? Sure, yes for the menial tasks, but definitely not for high stakes complex products. Same as generative art - it may replace the need for those filler banners, stock photos, redrawing characters a little bit differently for that last panel - but no, you don't generate a coherent, entertaining 100 chapters manga with generative art.
I thought the whole reason for encrypted connections is to deny information as much as possible from intermediaries (ISPs), so those who control servers can hoard all the information to their own benefit?
In virtually every country, there exists the definition of legal tender, which basically is the currency that taxes are paid and the currency that courts recognize as viable payment for debts.
So really, in FreedomLand, you can work and get paid in BTC, but if FreedomLand only recognizes FreedomDollar as legal tender, then when you need to pay income tax, the government will charge you in FreedomDollar, and you need to exchange your BTC to FreedomDollar.
If you cannot or don't want to pay tax, then of course police will prosecute you, and courts will also require settlements in FreedomDollar. Nevermind you have millions of BTC or XBoxes.
Now of course, this "problem" would disappear if FreedomLand recognizes BTC as legal tender, but now FreedomLand government loses all monetary control, and then economic activity descends into chaos.
I would say it is not about writing style but more about the personality of the author. According to MBTI for example, people are either Thinking (T) or Feeling (F), and I would imagine that strongly Feeling people focus much more on emotions (as compared to Thinking people) when expressing anything - be it talking, writing, etc. To them, the expression of emotion towards a particular subject is as important, if not more, than the objective value / knowledge / information imparted.
I can also hazard a guess that there are more Thinking people lurking in HN vs Feeling people, thus the general repulsion towards that style of writing.
I would imagine that a "real programming language" here means not only any Turing-complete language but also a language that has been consistently at the top 10 most popular programming languages in the world for a while (which javascript is, and typescript is its superset).
First of all, determine what value you bring with the certificates to various parties. In certified fields such as law, accounting, medicine, service providers benefit from high barrier of entry to market and high quality of the profession, whereas customers benefit from consistent quality and check & balances by law (via revocation of licenses if found to do malpractice). Governments benefit from increased surveillance and ability to regulate practices.
In software development, these and other benefits are not as critical or very hard to achieve even with strong enforcement.
> Do the best tools able to solve this in a satisfactory manner(the tool issue, the organizational issue) ? How ?
The best solution is I believe relentless continuous manual curation, which is discussed below. Automated tools are rather frowned upon in this area because I don't think there is any that is good enough until everyone is comfortable to rely on the black box.
> Can't this be done in parallel ? and why are resources an issue for such an important thing with a clear health ROI and maybe financial ROI ?
It definitely can be done in parallel. It takes years mainly due to political issues - like doctors arguing against each other which treatment/alert/option is the best, doctors/nurses/pharmacists arguing against each other who needs to look out for certain alerts, etc. We are not talking about tens of alerts, the number usually comes up to thousands.
Resource is an issue here because the best people to manually curate are the healthcare professionals themselves, but they are usually, you know, treating patients, so they are hard to find on their desks. And as mentioned elsewhere, the industry is highly hierarchical, so a bunch of minions can propose changes to alerts but everything needs to go to some higher authorities because the stakes are too great. Sometimes this "higher authority" does not decide without a formal consultation with some other authority. (nobody wants to be blamed if an error happens because the hospital just removed a perceived low-quality alert a week ago)
Coupled with the need to perform lots of research to produce high quality alerts, I would presume only large-ish hospitals / clusters (perhaps > 1000 combined bed capacity) can afford full-time people to look into this.
If only everyone has your mindset. Patients do complain - a lot. They never think that waiting another 1 hour is okay because it makes things safer - what they think is that they (or the insurer / government) have paid us handsomely, they want to be treated ASAP, anything slower means they don't get what they deserve. Less prominently but still important is that individual departments are usually under pressure to show that they are progressing to be both safer and faster / more efficient - thus they might make slippery and controversial trade-offs.
There are important KPIs related to patient health and public health that depend on speed, such as length of inpatient stay, transit time in the ER / ED, time to first antibiotic treatment, turnaround time for medicines and supplies. Compromising these KPIs may lead to non-optimal care too regardless of patients complaining.
I completely agree, although the attitude at facilities where this has been done extensively is always "how can we reduce the alert/popup/notification burden" because it always invariably slows things down and annoys people. And after a while the muscle memory stuff comes in as well - a typical alert can pop up tens of times a day with very high false positive rate.
An automated "checklist generation" is easy via subscription to data vendors, whereas manual curation takes years (even when only codifying best practices). And we can't just have one set of alerts for the world because everyone's (patient demographics, risk appetite, clinical sophistication level, computer skills, political situation) is different.
I am not a doctor, but I do have several practical defenses (I don't want to go through political ones).
There are many business processes in the healthcare field, and the impact and ease of imposing checklists will be naturally very different for each:
* Diagnosis and treatment protocols / pathways - these span long periods of time (days to months), any checklist will probably be quite complex and redundant to the already existing longitudinal case notes.
* Procedures (like surgeries) - some parts like preparation can be subject to checklist. But the procedure itself may need >= 2 clean hands and good concentration, thus glancing over checklists multiple times during procedure, or worse attempting to tick off stuff might cause more harm than good. (don't tell me to add one more guy there - we need him to save another patient, and google glass is dead for now)
* Processes related to ordering, dispensing, and administering medicines: there are probably tens/hundreds of thousands of these processes happening in a hospital at any given day. If a checklist introduces speed penalty it will be rather burdensome for the facility (and patients too). Furthermore, an equivalent of a checklist (e.g. refusing to proceed unless certain required fields are filled) has usually been codified in the hospital systems being used. Also, I feel that adding a checklist for something that you do hundreds of times a day, will not achieve anything, because the muscle memory will take over - you will just do things as per usual and sign off "all done" on the checklist, because you always do them all the time whether you remember or not, right?
This is already being done in a small number of hospitals in the USA and other parts of the world. The problem is mainly the resources (money and time) needed to repackage all the drugs to their own unit doses fast enough. Most of the time a barcode / QR code / equivalent 2D printed codes suffices and is much cheaper (and more flexible) than RFID tags.
However, you won't believe the kind of things that go wrong with this approach either. It's basically operating a manufacturing plant inside a pharmacy / hospital, but without presence of anyone titled "engineer".
In an ideal world, the drug authority (FDA) would require all manufacturers to print proper barcodes in all unit doses at the time of manufacture.
It's a question of resources as well. Adding checklists means more time and audit needed. Let's say something initially took 30 secs (due to the muscle memory prowess of the health workers) but by using a checklist it gets down to 45 secs - a 50% increase in latency. If this process is done 10000 times a day (a respectable number if you consider high-volume processes like administering a drug):
* you might have just increased manpower requirements across the board by about 50%
* you might have just caused patients to wait over the phone 50% longer, or queue to get their medicine 50% longer, or wait for the discharge process to finish 50% longer...
But among those 65000+ animals, only one has successfully increased its average lifespan significantly in the past 1000+ years. Chief reasons being advancements in sanitation, medicine, and overall diet quality. So "going back to nature" cannot be naively taken as always good.
I would actually think otherwise. The message format standard commonly used to pass HL7 messages right now are quite easy to parse, it is basically a CSV file using pipes and carets as field separators. Any technology worth integrating right now speaks HL7 one way of another already. Even if some reverse-engineering is needed, it is a 100% technical endeavour that does not need any political buy-in (except budgeting) - this is what I like to define as "annoying sort of a problem".
> If all the vendors spoke JSON (or some common, generic format) then you would only need to figure out a mapping for each vendor to your unified, internal schema.
This is not easy at all if your internal schema has less fidelity/dimensionality than the vendor. Expanding on my example above, suppose you have a smart weighing scale a la Withings scale that integrates with the EMR. The weighing scale has the patient's height input so it is able to send BMI <http://en.wikipedia.org/wiki/Body_mass_index> reading to the EMR as well. However, your EMR does not have a field for BMI because it is a computed/derived value of weight and height.
If your internal schema has higher fidelity than the vendor, you also are forced to impute data - this is not as bad but may cause unintended behaviours as well. A contrived example: the weighing scale only has the patient's identity information. However in your EMR the weight readings can only be stored associated with a visit/encounter (aka a hospital stay or appointment). You can associate the reading with the last open visit/encounter, but this will have undesirable repercussions e.g. during system downtime (it might become associated with the wrong visit).
There are ways to solve the above integration issue but they would cost a lot and may significantly impact the EMR all the way to end-user UI. So it is not only a technical issue but also whether the users are comfortable with the amount of complexity introduced in the UI, data imputation, etc.
Besides the counter-examples already mentioned, healthcare is already relatively unsafe - there are more people who die from medical errors compared to plane crashes, despite whole industry focus towards safety. Nobody wants IT experiments that magnify these numbers.
Another more feeling perspective is that in healthcare, errors cause real harm to individuals that you see and care for on a daily basis. Most errors can be attributable at least partially to a specific human that care for the patient. This surely has much higher psychological damage than a very occasional loss of 200 passengers that are not even your countrymen in a plane crash, or a loss of a few million dollars that is not even your own money to begin with.
Doctors ask "have you ever treated a patient?"
Pilots ask "how many flights have you flown?"