back to article Your pacemaker should be running open source software

Software Freedom Conservancy's (SFC) Executive Director Karen Sandler was last year awarded an honorary doctorate by Belgium's Katholieke Universiteit Leuven for her work for open source and software freedom. There was only one problem. Her heart was beating strangely, and she couldn't get the data out of her implanted …

  1. KittenHuffer Silver badge

    The CEOs ....

    .... of the companies involved should be forced to have at least one of their IMDs fitted to them. Just to show that they are sure that they are safe from hacking!

    1. Wellyboot Silver badge

      Re: The CEOs ....

      And required to attend certain security conferences that have a practical application leaning?

      1. Anonymous Coward
        Anonymous Coward

        Re: The CEOs ....

        I'd gladly sponsor one of them to attend BlackHat. Perhaps others would sponsor additional relevant medbiz execs, as well. The execs' names, companies, and job titles would appear prominently in the conference's promotional materials, of course!

    2. Andy_bolt

      Re: The CEOs ....

      Probably the only area of life with more caution in how things are regulated might be pharmaceutical or aviation. My wife works in this field. After hearing the culture that exists in this space, I had zero problem getting a medical implant from a firm she used to work for. It is a lower risk implant than a coronary one but companies that make these things take their responsibility seriously.

      1. An_Old_Dog Silver badge
        Flame

        Re: The CEOs ....

        but companies at least one company that make these things take their responsibility seriously. FTFY.

        If many companies did take their moral and technical responsibilities seriously, then we wouldn't have situations in which only company magician X -- currently unavailable -- can access the data. And, we wouldn't have situations in which security is a piss-poor after-thought, or even a no-thought!

    3. bbenoe

      Re: The CEOs ....

      ... and all political decisionmakers should be on open air while wars started by them are not over. Very realistic

    4. BPontius

      Re: The CEOs ....

      Like the Founder\CEO of Lifelock that had his identity stolen several times from his own systems. I thought that was poetic justice!

  2. Charlie Clark Silver badge

    Going nowhere but there are alternatives

    It's difficult to see any real path to success here: legally, there's no difference between a medical device and anything else we buy the software can be considered the IP of the manufacturer.

    But the data collected by the device is another matter entirely. This should be clearly documented and the patient and/or their clinician should be given the means to access it and control who else has access. This is much easier to legislate and implement.

    1. ChrisC Silver badge

      Re: Going nowhere but there are alternatives

      Exactly. Equally, just how far does opening up the device design (it wouldn't just be the firmware we're talking about here - you'd probably also need the schematics to know how to connect to the physical comms interface) actually need to go in order to be considered open source? Because presumably I could see a time when a manufacturer does open-source their firmware and hardware designs to enable third-party scrutiny, yet uses encrypted comms to which they alone hold the key, making it still impossible for anyone else to talk to the devices even though they now have all the data needed to fully replicate one.

      So this idea that open source == open comms (or, as the article is implying, that closed source == closed comms) is a fallacy - if the issue is that we want doctors to be able to have immediate access to patient data held on implantables/wearables, then the solution is making sure the comms interfaces are open, doesn't matter in the slightest whether or not anyone outside of the manufacturers has access to the underlying source code, schematics etc.

      1. KLane

        Re: Going nowhere but there are alternatives

        Having a read-only access method, that any doctor, or really anyone, could use, is too difficult for them <sarc>?

        1. Graybeard

          Re: Going nowhere but there are alternatives

          Surely the "thought" process is:

          1) this data is sensitive and important

          2) that means it shouldn't be easily accessible

          3) I know, we'll make it so only a trusted (!!!) company rep can access it

          4) surely we'll have plenty of those available 24x7x365 because #1

          But then it never gets communicated (or at least understood) and #4 never happens, because that would cost money and someone's bonus depends on not spending money.

          Either that, or Fred, who was responsible for one of the key steps in the process, quit or got RIFfed and nobody took the task on.

  3. Mishak Silver badge

    Functional safety

    What is needed is the proper enforcement of functional safety standards on these devices - the current medical standards are not fit for purpose, and (some of) the medical device companies are lobbying to prevent there being any changes.

    And then there are the user interfaces - there were (are?) infusion pumps that give orders of magnitude different doses for what appear to be the same settings (and this has lead to serious accidents).

    On its own, opensource will not help as the code is generally not compatible with a number of the objectives that have to be satisfied when functional safety is required (where are the formal requirements, test plans, etc. ?). However, there is nothing to stop an open source project from being created that does tick all of the boxes, though many will not what to take part because of the amount of (tedious) supporting documentation that needs to be provided.

    1. Mike 137 Silver badge

      Re: Functional safety

      "On its own, opensource will not help as the code is generally not compatible with a number of the objectives that have to be satisfied when functional safety is required"

      That applies to the volunteer development community, but that's not the entirety of open source. There's nothing to stop a critical system vendor fulfilling all the necessary objectives before releasing the source. However, in the life-critical application space, full public disclosure would probably be counterproductive, as all software has bugs and it wouldn't be a good idea to alert malicious actors to them before they can be fixed. A system whereby the source could be released on demand to authenticated legitimate independent examiners would serve the necessary purpose though. The problem of course is that "intellectual property rights", for most vendors, cap potential hazards to users.

  4. Sir Sham Cad

    Certifications for Medical Devices

    Part of the issue re: security of Medical Devices generally is that they are shipped to the Clinicians essentially as a Black Box that has a Certification for use as a Medical Device. Usually certified several years previously. Any "change" to the state of that device, for example: patching the underyling OS, deviates from the original specification meaning the device is no longer certified and can't be used.

    Essentially, Medical Devices are a huge security problem because they, and the whole ecosystem is designed for a point-in-time configuration not security.

    1. Matt Korth

      Re: Certifications for Medical Devices

      I work on pharmacovigilance software, and this is essentially correct. You're describing the requirements for validation.

      You *can* update the state of the device. You can patch the OS. You can update the code. *But* if you do so, you have to revalidate it with the new configuration - basically, produce a whole metric craptonne (it's 10% bigger than an Imperial crapton) of documentation that the device, with its new configuration, still meets its formal specifications. This can be done by either the manufacturer, or the user, but it *does* have to be done to comply with medical regulations. It's a royal pain.

      There's nothing preventing you from making the software open source, but the issue is that you can't just update it at random and remain in compliance.

      1. Bebu Silver badge
        Headmaster

        Re: Certifications for Medical Devices

        《metric craptonne (it's 10% bigger than an Imperial crapton)》

        I take it that is a short imperial ton? Or is merde 10% denser than anglosphere shite?

        Why is one still calling avoirdupois etc "Imperial?" I thought the UK went metric yonks ago, not only is the Empire long gone, the former possessions are repaying the "debt" by providing comparably competent rulers in Westminster today. :))

        The only nation that avoirdupois etc now has any legal currency must be the US? Probably time to call these units US ton or 'Murcan ton. Only readers of old manuals and old cookbooks need to know these old units - the difference between US and Imperial pints for example and even then treading carefully.

        1. Richard 12 Silver badge

          Re: Certifications for Medical Devices

          They are technically called "United States Customary Units", not imperial.

          1. MarkTriumphant

            Re: Certifications for Medical Devices

            That would very much depend on being in the US. In the UK we say "Imperial" or "avoirdupois".

            1. Richard 12 Silver badge

              Re: Certifications for Medical Devices

              Ah, but several US Customary Units are different to Imperial.

              Thus increasing the ridiculousness of them 12 (or is it 16?) times over.

    2. ChrisC Silver badge

      Re: Certifications for Medical Devices

      Similar for a lot of other types of embedded system as well - for the emergency comms stuff we develop for parts of the world which require UL certification, its granted for a specific combination of hardware and firmware revisions, and any deviation from either would require at best a paperwork exercise and at worst a full system retest from the certification body.

  5. gnasher729 Silver badge

    Independent of open source or not, it should be easily possible to extract data from these devices. Say some Bluetooth interface that can send the data to my iPhone. Or android phone.

    For security, having a gut repository with public read-only access would be a great way if you don’t want to open source it. I mean I’d love to have this software safe, but I really don’t think having different versions would be a good idea.

  6. Andy 73 Silver badge

    Hahahahahaha

    If you want to know why this is so difficult, take a look at the American medical insurance industry and consider the issue of medical regulation.

    You want both security AND the ability to easily pull data from device? You want to prevent hacking AND share all of the code with the world? (No, sharing code does not magically make it secure). You want changes to software not to put people at any increased risk AND have them every three months? You want companies to spend years and billions of dollars not only developing this technology, but also going through the costly process of approval AND have them share all their work in public for free?

    That's a lot of contradictory requirements, most of which overlap hugely with regulation, safety, corporate governance, costs and highly specialised workers.

    1. John Robson Silver badge

      Re: Hahahahahaha

      Those things are not contradictory.

      Why would closed source software be safer than open source?

      Security by obscurity it not security, it' just obscurity.

      Patient access to pull data does not require it to be broadcast to all and sundry - only needs one key to be available (and copied into the device) - the patient will share it with the appropriate clinician. They could even update it if they think it's been leaked.

      There could be an unauthenticated "what (basic data) happened in the last two hours" for emergency services as they start to put defib pads in place, but that might not even be needed.

      And requiring critical software to have updates when vulnerabilities are found is the minimal effort required.

      1. Andy 73 Silver badge

        Re: Hahahahahaha

        Note I never claimed closed source is more secure - just pointed out that opening source code up does not magically make it secure, but without question does make it easier for people to look for vulnerabilities. There is an important difference here between the idea of 'security' and 'vulnerable to attack'. I can grep "software that uses library X with newly discovered vulnerability Y" in moments on GitHub.

        Equally there is nothing about software being closed source that prevents it from having sane data availability. Clinicians and insurance companies should probably make this a base requirement for any device they approve for their patients. The fact that they don't probably says more about how they think about such devices than the implementation choices of the manufacturers.

        The same applies to updates - and I note that a family member with a pacemaker had regular updates on the 'high end' unit she had fitted, and almost none on the 'standard' one - this is entirely under the control of the medics (and, sigh insurance and government) that make selection decisions between devices. Whether or not it's open source is utterly irrelevant.

        1. Charlie Clark Silver badge

          Re: Hahahahahaha

          For large scale attacks fuzzing is now the weapon of choice. Sure, if a quick static analysis reveals potential vectors, they can be considered nice to have, but the best thing is simply run attacks in a sandbox and keep the results quiet.

          Medics are notoriously unqualified to assess the safety of software devices. You really need trained engineers for that who can get the necessary medical information from the clinicians. But we then run into the usual problem: regulators are underfunded and understaffed, so lightweight "self-regulation" usually gets the nod: medical devices, cars, planes, financial products, etc.

        2. This post has been deleted by its author

  7. Andy_bolt

    First hand experience

    It seems odd that the pacemaker implant could only be read by the manufacturer. I could see a point in limiting ability to tweak settings and maybe they locked down any access. That said, read only access to the data should be very low risk. Certainly lower than someone going in and tinkering with something that could kill your if you’re not perfect in your coding.

    Regarding software bugs, the bugs may exist as they do in every piece of software but aren’t of a magnitude that it would trigger a recall by the regulator.

  8. P.B. Lecavalier

    corporate says...

    "We have spent millions in developing this intellectual property. What we have is an industrial strength product."

    What they don't tell you is that it was written in assembly by a lone hobbyist programmer.

    What could possibly go wrong?

  9. GoneFission
    Devil

    This seems like an untapped market for recurring subscription services. Want read-only access to your pacemaker data? Pay us $20 a month and we'll show it to you on a janky dashboard our intern slapped together in Flask. Until someone in a boardroom gets a whiff of the idea, and then it'll quickly turn into "pay us a monthly fee for the device to continue functioning"

  10. Anonymous Coward
    Anonymous Coward

    Thanks for this story!!!!

    I just had an ICD fitted 4 weeks ago. Tomorrow is the first day that I am allowed to drive again, after the legal 4 week break.

    That made my heart miss a beat- allegedly - I cannot access the data.

    1. Arthur the cat Silver badge

      Re: Thanks for this story!!!!

      I came here to say much the same. Totally made my day, given that I'm on my second pacemaker.

      However, the story doesn't make that much sense to me. Although my GP can't get data out of my device, the local hospitals have loads of mutant laptops in heavy duty cases that can, plus cardiac techs and cardiac nurses who can operate them as well as the cardiologists. I've also got a remote unit at home that will send a read out over the mobile phone network in about two minutes, so the idea that only a company rep can get the data either isn't right, or whoever chose to use those devices should be fired.

      1. Richard 12 Silver badge

        Re: Thanks for this story!!!!

        This is in the US.

        Aside from that, the need for "mutant laptops" is the real problem. The comms is closed proprietary, and the manufacturer has no incentive to write decent software for reading & configuring.

        So it ends up with every brand needing a laptop running a specific operating system version, that cannot ever be updated lest it break the fragile custom software.

        It's not the only such industry of course. How many ATMs still run Windows XP, for example...

    2. Anonymous Coward
      Anonymous Coward

      Re: Thanks for this story!!!!

      I've had a St Jude ICD since 2007. I'm on my third one now (they get replaced - surgically - about every 5-6 years). From the second one onward, they've been running Open Source code. Just for grins, I downloaded and disassembled the code a few years ago. It's nothing particularly revolutionary, and it has proper passwords for parameter changes, and those changes can only be practically done from one of their specially configured (running Debian) laptops.

      When I was having the third one installed, there were engineers from St Jude's visiting the hospital, and I had several hours with them (I'm a retired engineer) and found out a lot about their electronic design too. It's a fascinating technology, and has kept me going since 2008!

      The code for the ICD is actually just about what you'd expect, but has some pretty nifty logging routines. For the sake of safety and my own sanity, I won't go into details about its operation.

      1. jake Silver badge
        Pint

        Re: Thanks for this story!!!!

        This is part of the reason I read ElReg.

        Thank you for your first hand input, all y'all. This round's on me.

        Yes, I know what a testimonial is. That doesn't make this kind of comment worthless.

      2. An_Old_Dog Silver badge

        Why Would "Open Source" Need to be "Disassembled"?!

        Just for grins, I downloaded and disassembled the code a few years ago.

        See title.

        1. jake Silver badge

          Re: Why Would "Open Source" Need to be "Disassembled"?!

          I could hand you an executable assembled by my personal assembler (or compiled by my personal compiler), along with a tarball of what I claim is the full, complete, unadulterated source.

          How are you going to verify the executable is actually built from the contents of the tarball without access to my assembler or compiler?

          1. An_Old_Dog Silver badge

            Re: Why Would "Open Source" Need to be "Disassembled"?! / Lack of Effective Crypto Verification

            @Jake: the poster I replied to wrote they had "downloaded and dis-assembled the code." If you have the source (as he did), which you (he) just downloaded, that source file doesn't need to be, and can't be, "disassembled," because it already is in source form. Are you thinking the poster dis-assembled the binary provided with the device, and compared the disassembler-generated source file to the publicly-released source file? Doing so is almost-guaranteed to result in a mismatch, even if the binary and source are uncontaminated.

            But your general point as I understand it, while not addressing what was actually written by the OP, is extremely-relevant.

            I once downloaded the assembly-language source of a program I use fairly extensively, "GRUB4DOS", and assembled that source (the same version as I was using: "0.4.5c"). I did a SHA256SUM on the binary of the freshly-assembled source, and of the binary package I had downloaded. They did not match! Why not?

            * Did the author use a different assembler than I (a near-100% likelihood), with different options, resulting in different binaries?

            * Did the author use a different source file -- with some sort of back-door included -- than the publicly-available source file purported to be version 0.4.5c?

            * Did some asshole exploit the website and replace the author's binary with one which said asshole had modified to contain a back-door or other malware?

            I had scanned the binary I had downloaded at VirusTotal.com, and via locally-installed ClamAV, before I used it. The ani-virus and anti-malware scans reported nothing bad was found. It's a problem that many freeware/shareware/open-source authors and organisations do not use effectively-strong cryptographic verification methods. Throwing up a "Here's the SHA256SUM (or MD5SUM) of the binary" on a website is ineffective because that site might become compromised, and the attacker could simply change the text on the website to report the checksums of the now-malware-laden binary.

            Don't even get me started on projects for which the installation procedure is, "Download and run our magic CMD file/PowerShell script/BASH script -- as Administrator/root."

            1. doublelayer Silver badge

              Re: Why Would "Open Source" Need to be "Disassembled"?! / Lack of Effective Crypto Verification

              Don't even get me started on projects for which the installation procedure is, "Download and run our magic CMD file/PowerShell script/BASH script -- as Administrator/root."

              In virtually all cases, you can clone and build yourself just fine. The script is there to make that easier, and it needs root for the same reason that most installers ask for it: it's going to be installing the program in the typical places, for example /usr/bin, and your user does not have permission to write to that. This is especially true if it's also installing a service, cron jobs, manual entries, modifications to a linked configuration, etc. You can usually replace that instruction with clone, configure, make, and manually move files where you want them, but since that's not what most users are doing, it's not the script they write.

              What do you think they should be doing instead?

              1. jake Silver badge

                Re: Why Would "Open Source" Need to be "Disassembled"?! / Lack of Effective Crypto Verification

                "What do you think they should be doing instead?"

                Force the user to install as an ordinary user, asking for the root/administrator password only as actually needed, and warning if anything is about to be written over as root. (Granted, the average idiot will just answer "yes" to "<blink>Warning!</blink> The INstant Internet Terminal installation procedure is about to overwrite the file "init"! Y/N?", but you can't always protect against the completely ignorant, just minimize the damage. Hopefully.)

                Obviously, if the user doesn't have the password, abort the install, and clean up the mess before exiting.

            2. jake Silver badge

              Re: Why Would "Open Source" Need to be "Disassembled"?! / Lack of Effective Crypto Verification

              I assumed (yeah, yeah, yeah, I know) he downloaded the binary because he used the word "disassembled". Presumably he downloaded a copy because he didn't feel comfortable extracting a copy from the device that was keeping him ticking over. Which is quite understandable. We'll never know, unless the OP cares to comment.

              As for the rest of yours, see ken's classic 1984 address to the ACM titled "Reflections on Trusting Trust".

              Am I the only one who reads "ICU" as "In circuit debugger"?

  11. BinkyTheMagicPaperclip Silver badge

    Citation needed on open source software being better over time

    Seriously, OpenSSL springs immediately to mind. It needed a disaster to sort that one out.

    Open source could possibly help but the real issues are extensive testing and certification, and more importantly open standards for extracting data. It is incredible there is no external code review on these devices.

    I definitely agree it's unreasonable that only the vendor involved can easily extract data, their software should be readily available for medical professionals by law.

    1. Andy 73 Silver badge

      Re: Citation needed on open source software being better over time

      Not wishing to be cruel, but "someone who's career is focussed on championing open source encounters a problem that they believe only open source could fix" is not exactly a shocking turn of events.

    2. Snake Silver badge

      Re: Citation needed on open source software being better over time

      I agree. For decades we've heard "many eyes on the code!" as a plan for FOSS security and it was a dog whistle. OpenSSL, Log4j, Glibc, Dirty Cow, Shellshock...

      So exactly how many people were indeed downloading that source code and then both reading and understanding it? Not as much as the hype led the world to believe.

  12. Anonymous Coward
    Anonymous Coward

    Liability

    I suspect the driving force behind the lack of open source as a solution is the liability issue. CEO John Doe is probably uncomfortable being the material risk taker when the software isn't written by someone he's legally tied to, either through employment or contracts.

    Not to say it's a better solution or otherwise, but that's almost always the issue.

  13. Starace
    Devil

    Sounds... unlikely

    So she announced a scenario she experienced as a hook to go off about medical device software being open.

    Problem is it doesn't add up. Manufacturer representatives aren't the only ones who can pull the device data, there's plenty of others who could including her cardiologist. Or anyone else in the same profession with the interface kit. It's routine. There's even kits for patients to pull data themselves for home monitoring & diagnostics.

    The problem comes from travelling well outside the market where that device was sold and that's not solved by open source, it's an interface standards issue between markets. And even where standards exist open sourcing the core runtime isn't going to have been the solution to getting an EU cardiologist to pull data from a US device if the standards aren't aligned and no one local had the right kit. Same issue exists for all sorts of kit.

    And open sourcing certainly isn't going to be a panacea for any issues that exist, there have been some horrific security issues with widely used well scrutinised open software. At least the medical device has had to meet the appropriate development & certification standards so even if not perfect it's still not going to suddenly be much better because you've let a crowd of randoms browse a load of esoteric high reliability embedded code.

    Of course the solution that appeals to a lawyer doesn't necessarily have to rely much on facts or reality...

    1. Roland6 Silver badge

      Re: Sounds... unlikely

      Agree faulty diagnostic and reasoning: The problem was firstly her lack of a reader to hand - remember this was a “life and death” situation.

      Secondly, having got the data she would have to had the right application (*) to make sense of the data.

      (*)Right application includes a spreadsheet with appropriate layouts, formulas and graphs capable of importing data set. But in todays world it’s a phone app.

      >” One of the reasons why people get these devices is so they and their doctor can track their condition”

      Clearly this was not the case here, otherwise her cardiologist would have selected a model that had a data export function they could use and the tools to read the data and given her the app for her phone so she could monitor it.

      The open-closed source debate is a red herring in this instance; if I were an investor in the SFC, I would be raising questions about the competence of the executives…

  14. Herby

    Pacemaker software...

    Is a strange thing. I worked on one while back and noted a bunch of things. The device was based on a 65C02 and ran assembly language. It had a timer that turned on the CPU every beat to save power (one half of the device was its battery). When they shipped the thing out, they included a dedicated laptop to interface with the thing (simple expense) that was the monitoring software. Cost wise about 1/2 of the cost was liability insurance (I believe that was the number), and to total cost was over $20k (back in 2000). My function was to test the silly thing (we had a bog breadboard we used). To do the testing we had a setup of 4 desktop machines to simulate the patient and record results. They were concerned about interference that they had to switch off ethernet access to the switch because they thought it might interfere with the testing. I worked on trying to make sure that all the execution paths worked correctly by devising several procedures to check all the "if then else" sequences. All of this for a device that was smaller than a deck of cards. Of course it could have been "open source", but there was a certification process that was tedious to say the least. All in all an interesting project. When you get into medical devices everything is difficult. If it weren't you wouldn't trust it AT ALL. Yes, data dumps should be easy to get, but nobody has setup any standards. Until then I don't hold out much hope.

    Life goes on, one beat at a time.

  15. ldo

    Remember The CPAP Hackers?

    Anybody remember, during the initial bad old days of the COVID-19 pandemic, some security researchers discovered how to hack a CPAP device to make it function as a ventilator? This opened up a legal can of worms, but given the urgency of the need, with people dying daily, it seemed a better risk than doing nothing at all.

  16. Bebu Silver badge
    Windows

    A heart transplant might be safer...

    When I was reading this story SNMP jumped into my mind ... I think the dark side is calling ... just install an SNMP agent on the device and publish the device's MIB what could go wrong?

    History would say heaps.

    At 70k lines of code that is a lot more than I would have imagined but I am pretty sure that the one bug per 100 lines is pessimistic but without a verifiable (formal) specification that defines the behaviour of the device who is to say what is a bug.

    In the pacemaker case I would assume the cardiac stimulus would be provided an autonymous hardware signal generator and timing component and that the processor's software only monitors, logs and fine tunes the autonymous hardware.

    If your pacemaker's software borks you still have limp mode. Pretty much what the heart itself does. :)

    I assumed that medical devices used software like AdaCore's SPARK Ada to develop the soft-/firm-ware and the idea of coding in assembler or C is frightening.

    The article's main or at least addressable gripe was data access for clinical purposes. This could be remediated by layered standards and once you get to the application layer its just the format of the records that requires specification and definitely wouldn't require ASN.1.

    Vehicle control computers suffered from the same nonsense but I believe was becoming less of a problem... pre Tesla/EV anyway.

    To think Musk wants to put an IMD (neuralink) in your brain. You wouldn't need Tesla FSD to T-bone another vehicle your implant will save it the trouble.

    1. Graybeard

      Re: A heart transplant might be safer...

      Agreed, a bug per 100 LOC seems very pessimistic in something that's firmware. Not because firmware is magically better, but because the cost of updating devices means that ?most? companies realize that it's worth spending a bit more QAing firmware than it is on QA for their glitchy website, which can be updated instantly(ish).

      With over four decades in the software business, I'm by no means suggesting complacency: our industry has serious problems, and this case appears to exemplify several of them. This XKCD:

      https://xkcd.com/2347/

      is 100% correct. I wake up every day wondering if this is the day that everything breaks. But exaggerations like 10 bugs/KLOC don't help, as they're too facile and make it easy for the people who *can* do something about it to dismiss articles like this.

  17. Version 1.0 Silver badge
    Boffin

    And other potential issues

    Errors in the software are potentials but open source helps everyone find them. However while an EKG interpretation issue could be a software error, it's also possible for the software to be processing data collection errors in a medical/technical EKG data collection environment, often an array of electrodes are placed on the subject accurately over the heart but over time the electrodes can become loose and then stuck back on in a different location ... so there may be a slightly different data collection even if the heart contractions have not changed.

    This is just an observation of issues that I've saw 40 years ago when I was working to collect accurate EKG data for doctors, I didn't tell them that they had made an error, they always told me exactly what had happened when we examined the raw data ... people collecting data often spot errors that software spins past.

  18. BPontius

    Looking at the wrong issue

    The issue isn't closed or open source code, the issue is implementing security to prevent hacking of these devices. These devices are too open to outside access. We need to end the remote access mentality for everything; medical devices, cars, utilities, industry...etc, some systems need to be in-person hands-on with no exceptions. I am at a loss as to why cars need remote access to internal systems, any command, diagnostics or troubleshooting should be done on-site not remotely. As long as security is an after thought, these problems will only get worse no matter the access to source code.

  19. Grogan Silver badge

    Sorry, github is down, we can't install your pacemaker without commit f6445dc94da185b3d1ee283f0ca0a34c4e1986cc :-)

  20. EricB123 Silver badge

    Maybe they could sell an update subscription?

    I had an implant installed 7 years ago. It wad supposed to improve the quality of my life, for, well a lifetime.

    It has broken twice already. Guess who is stuck with the surgery bills to fix this POS?

    Um, hello FDA?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like