Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
https://spectrum.ieee.org/files/17305/08 Spectrum_22Med.pdf retrieved on 02AUG2022. IEEE membership might be required to access.
“Medical training in the robotics age leaves tomorrow's surgeons short on skills.”
“Once the robotic arms are in place and instruments are inserted, the surgeon ‘scrubs out’ and takes up position perhaps 15 feet away from the patient in the immersive daVinci control console, which provides a stereoscopic view. The surgeon's hands are on two multipurpose controllers that can move and rotate the instruments in all directions; by switching between controllers, the surgeon's two hands can easily manage all four robotic arms.”
“And the trainee… well, the trainee gets to watch from another console, if there is one. While the lead surgeon could theoretically give the trainee one of the robot arms to control, in practice it never happens. And surgeons are reluctant to give the trainee control over all the arms because they know that will make the procedure take longer, and the risk to the patient goes up nonlinearly with elapsed time under anesthesia.”
Sawbone v. Robot patient outcome comparisons for certain procedures, such as prostate surgery, are challenging to interpret. Why?
The FDA is required to collect and report data for adverse events. The medical device reports (MDRs) document and standardize adverse event resulting in patient injury, death, and device malfunction. MDRs are almost exclusively prepared and reported by device manufacturer representatives: significant subject matter expertise necessary to accurately document an adverse event.
The FDA is NOT required to collect data on the total number of robotic surgical procedures performed over time. The robot surgeon device manufacturers know, but are not required to disclose.
This practice explains why most (if not all) long-term medical device recipient studies reveal events per population (usually per 100,000) per year. This data can be extracted from billing records kept at the Centers for Medicare & Medicaid Services (cms.gov). Trend reporting can smooth and obscure event clusters.
The total robot procedures performed, devices implanted/explanted or in-service per year constitute “proprietary data.” Expecting consumers to interpolate medical device counts or surgical procedures by examining MDR filings is burdensome.
Would a legal requirement for periodic manufacturer disclosure of aggregate medical device implants/explants or procedure counts improve safety? MDRs v. actual counts information may enlighten more than device per patient population trends.
Refer to https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfTPLC/tplc.cfm?id=5692&min_report_year=2017 from FDA's TPLC platform for Product Code NAY: System, surgical, computer controlled instrument. This product code groups several manufacturer devices into equivalent categories. Intuitive Surgical, Inc.'s DaVinci is prominently featured in the report.
The TPLC MDR summary shows robotic surgical device adverse event reports per year. That total adverse event-report frequency grows year-over-year suggests robotic-driven surgical procedures are in demand. In CSV format:
MDR Year MDR Reports MDR Events 2017 1049 1049 2018 1074 1074 2019 1154 1154 2020 1558 1558 2021 1997 1997 2022 2465 2465
“Break” or “Detachment of Device or Device Component” events characterize the most common robot surgeon faults.
Bad news for the owners of several Honda models, the Rolling-PWN Attack vulnerability can allow unlocking their vehicles.
Companies are racing to cool down their servers as energy prices and temperatures soar. And the worst is yet to come.
These controls, which are buried inside products from Apple, Google, Meta and others, make us share more data than we need to. […]
You may be hearing about this, and I'm not going to try critique it in detail here right now. But I will express an overall opinion of it. My sense is that it is an unmitigated mess. Nor is it obvious to me that it will ever not be an unmitigated mess. The list of reasons why is long and technical. But that's my executive summary for right now based on what I've seen about this to date. -L
In the 1970s, IBM sold the 370/145, which did not have virtual memory. Or at least, that's what the POP (Principles of Operation = instruction set handbook) said.
Being a moderately large customer, we had an on-site CE (repairman), with an office set aside for his use. There was a hardcopy listing of the 145's microcode (looking very much like any other assembly language) bound in a large folder in the office—which was not kept locked. One of our programmers, having some time on his hands was leafing through this out of idle curiosity and noticed that there were gaps in the address column:
10258 opcode operands 10259 opcode operands 10260 opcode operands 10536 opcode operands 10537 opcode operands etc.
“Curiouser and curiouser”. One of the things you could do at the console was to “coredump” the microcode to the console “typewriter” (a 120 cps dot matrix terminal). In hexadecimal with EBCDIC translation at the right.
Lo and behold, in one of the gaps there appeared the characters CROSS PAGE.
Well… wasn't that interesting?
He traced through the code and discovered that the machine came with virtual memory, but when you loaded the appropriate bit into the control register, the microcode would first check a “switch”—actually a wire that the CE could clip. We didn't actually own the 145—IBM was in the leasing business in those days—so we couldn't just take a pair of “dikes” and clip it ourselves.
No problemo. It turns out that the “control registers” were in the microcode address space.
He wrote a program called “wishbone”. Set the load address to 00C (the card reader), put the binary deck in the hopper, and push the IPL button. The program loads and just sits there. You then have 2 minutes to set the console dials to a particular address, push “set microprogram address”, then “start”. The program that was loaded into the registers would execute, and patch the microcode to ignore that wire and turn on virtual addressing. It would also print out “Wish granted”.
Then grab a copy of CP/67(*) on tape, IPL from the tape, and presto, you have a virtual machine.
If you did nothing for 2 minutes, or if you pushed any other buttons, the console would print out “Wish denied”.
[* CP/67 was a virtual machine OS for the 360 model 67. The 370/145 interface was identical]
About 6 months later IBM announced virtual memory for the 145, the CE clipped the wire, and we could run CP/67 officially.
Back in the good old days, there was an IBM card reader where the difference between the fast model and the slow one was a delay relay. Needless to say, academic departments all rented the slow one and bypassed the relay, and had to try to remember to put it back when the CE came by.
I also believe there were some small mainframes that were always shipped with the maximum amount of memory, with jumpers to enable the amount paid for.
On some models of IBM 1130, the CPU cycle time was deliberately slowed down, except that when it was taking interrupts from the printer, it needed to run at full speed to set the print hammers before the rotating print drum moved past the desired character position. You can imagine what students did with that.
This annoyingly bad idea goes way back.
You have a point—but for computer equipment, what's the alternative? Companies make entirely different device models to satisfy various price points? Make one mid-range model that doesn't satisfy most needs? Make one model for the largest demand and ignore the rest? How are those better than allowing one device presenting different capabilities to satisfy different needs/budgets? Why is it annoying or even bad, vs. happily meeting different needs at different price points?
In fact, why is enabling different auto features for different prices bad? Again, what would you suggest—configure different cars for different budgets? That's more expensive and requires more complex logistics, and who does it help? Always enable all built-in features? But then how to target different needs/budgets?
That's not defending rental model for auto features—it's bad enough that software goes in that direction.
IBM DOES allow rental of speed boost features on installed equipment to meet peak loads. That too satisfies customer requirements.
Or IBM's 1950s-1960s era line printers which were leased—not sold—at different levels of speed controlled, customers discovered, by jumpers on a plugboard. Remove a jumper to get the higher speed, no cutting required.
The web article doesn't support the claim in the subject line that using Google Search is “entirely prohibited”. In any case, it is quite reasonable to use DuckDuckGo instead of Google Search. GDPR issues aside, in a teaching situation, you don't want the “personalisation” features of Google Search as that could skew the search results—particularly if several people share the same computer.
> The wholesome Canadian chain caused a scandal when its privacy violation was > revealed, and now it's proposing a free coffee and a baked good as > restitution.
“Canadian”? Puh-leez. Tim's (and Burger King's) parent company is Brazilian.
But yeah, the proposed settlement is pretty weak cheese.
When I first saw this headline, I thought Tim Hortons was offering you free food in exchange for the right to spy on you. Not unlike the auto insurance “safe driver points” incentives, eh?
They could not have chosen a worse moment to petition for the abandonment of leap seconds, as the Earth's rotation is just now reportedly speeding up. We may need many more leap second adjustments.
There's a very low-tech solution to this problem (this image is of the yard of a newly built prison in Israel): http://www.hoek.co.il/wp-content/uploads/2015/03/250-ofek2.jpg
Note the mesh net over the yard. This has been the standard in prisons for decades now, to solve the low-tech problem of accomplices throwing stuff from outside over the fence.
“… if one business sets a price, the algorithm could automatically undercut it” — or else, if one business sets a higher price, the algorithm could raise its prices to match…
Consider it logically: when faced with these two choices, which one is the algorithm more likely to decide is more profitable for its company?
It still escapes me why the Echo and similar devices don't implement some basic voice fingerprinting to prevent random speakers from activating them.
While Alexa is not a very common name, it's still common enough to cause trouble for quite a lot of people (and their families). But now we are facing yet another level of this problem: One of the reactions quoted in this article is “Hey @Jeopardy please no more contestants named Alexa” — a new form of discrimination is born!
>Since then, “breakthrough cases” have become common, with triple-vaccinated >Americans regularly catching SARS-CoV-2 and staying sick for much longer >than the unvaccinated…
This is nonsense, and I am surprised you published it. The source is a Fox “news” piece. [*]
Nobody who understands medicine ever said that vaccinations would completely prevent infection, but there is overwhelming evidence that if you are vaccinated you are less likely to get sick, and you will get less sick if you do.
Please report problems with the web pages to the maintainer