标签: medical

Internet of Things enabling Health and Wellness The Internet of Things is not just a futuristic vision of a better connected world; it is already here, giving health providers an unprecedented level of technology interoperability and flexibility. IoT-enabled systems can radically reduce costs and improve health with improvement of care. Advanced wireless sensors and connectivity technology allows devices to collect, record and analyze data at the click of a mouse (or a swipe of the finger). The automation involved in gathering such data reduces risk of error and time which can potentially be useful in saving lives. The application of IoT in healthcare can improve the access of care to people in remote locations or to those who are incapacitated to make frequent visits to the hospital. It can also enable the prompt diagnosis of medical conditions by measuring and analyzing a patient’s parameters. The treatment administered can also be improved by studying the effect of a therapy on the patients’ vitals. One such concept is the Medical Body Area Network (MBAN) which refers to an application of wearable computing devices that actively monitor the human body’s vital signs (e.g.: heartbeat, temperature and blood pressure) and communicates wirelessly with a single body central unit (BCU)using wireless protocols. A glucometer device connected to a Mobile Application Source:ihealth.com The latest debuted iPhone6 from Apple includes a new Health app and associated tool for developers called HealthKit. With such features, connected medical technology can now literally be at one’s finger tips. For the Health app, Apple is looking at integrating Emergency contact cards with information like blood type, food allergies etc., which will be accessible in emergency situations. Other features include monitoring everything from the user’s heart rate to his or her chronic conditions. It also provides connectivity to third party fitness devices and applications like Nike+ or Fitbit which has the ability to collect information like heart rate, footsteps and sleep activity. IoT has been gaining a lot of interest among healthcare providers in India as well. A recent report from The Economic Times, mentions how leading hospitals in the country are now using IoT to improve the quality of healthcare they provide to their patients. Bangalore-based Manipal Hospital give expecting mothers a wearable device which when paired with a mobile phone application gives real-time information on the fetal heart rate, expecting mother’s blood pressure and other relevant data to the hospital information system which can use automated tools to highlight any anomalies. It can also alert doctors who can immediately initiate further tests to check for potential critical conditions like HELLP Syndrome which is difficult to diagnose but which can lead to fatalities. In the US, electronic health monitoring has been given the go-ahead by the Federal Communications Commission (FCC). FCC allows the use of allotted frequencies for sensors to control devices wirelessly in the monitoring of health at hospitals and homes. Such monitoring allows doctors to inform their patients of critical conditions before they happen and subsequently improves the quality of healthcare. There are many IoT-enabled devices which have already hit the market and which will be hitting the market soon. Examples are: infant monitors which send parents real-time data, wireless capsule endoscopy where the patient swallows a camera in a pill that moves through the GI tract taking pictures. Smart pill is a similar example which is an ingestible sensor that records various physiological measures. Novartis is partnering with Google to develop a type of contact lens which will help monitor the blood glucose level patients suffering from diabetes. Wearable and ingestible sensors that work together to gather information about medication-taking, activity and rest patterns Source: Proteus Digital Health   Elderly, Home bound patients and differently abled people are bound to see the largest benefit from remote monitoring and assistive technologies. There are several applications being developed that can help such people maintain their independent lifestyle – sensors on the person and throughout their home can help detect falls, wandering and even missed medication. Emergency call pendants can allow them to call for help when needed. A ‘smart’ prescription bottle could alert the user if a scheduled medication has been forgotten. Light and sound reminders on the pill bottle cap to signal the time for medications. Inside the cap, a chip monitors when the pill bottle is opened and wirelessly relays alerts . Source: Vitalityglowcaps.com The demand for high-tech healthcare solutions will continue to grow dramatically while also driving creative and powerful deployments of devices based on the Internet of Things. There are foreseeable issues with the use of IoT which include standardization, scalability and security, but these are minor issues when compared to the advantages connected technologies offer the healthcare segment.   -          Srinivas Panapakam, Vice President-Sales and Business Development

The medical imaging company I was then working for was involved Nuclear Medicine product development. The product was a scintillation camera, or gamma camera, used to image gamma radiation-emitting radioisotopes. The patient was given a radioactive-tagged pharmaceutical that was preferentially absorbed by the area of the body being studied. The gamma rays given off were received by a detector head, which outputted the X-Y position and energy of each photon received. These 3 signals were sampled at 14bit resolution. However, the data required 3 stages of correction to produce a usable image. In linearity correction, a correction vector is read from a stored table addressed by the observed X-Y position and added to it to produce the corrected X-Y position. Since storing a complete correction table at 14 bit x 14 bit resolution was impracticable, the correction tables were stored at 7 bit x 7 bit resolution and bi-linear interpolation was used to interpolate from the stored table. In a flood test with a linearity board using bi-linear interpolation, image artifacts were found, edges at interpolation cell boundaries in what should have been a uniform field after correction. This was brought up at a group meeting and all of us were asked to consider a solution. I remembered from an image processing class that the human visual system is sensitive to edges, and that edges are characterized as abrupt changes in the first derivative in space of an image. Bi-linear interpolation enforces continuity of the value of a function at cell boundaries, but it produces a discontinuity in the first derivative. I reasoned that such a discontinuity would produce the edge artifacts seen, so what was needed was an improved interpolation method that would enforce continuity at the cell boundaries in both the functional value and the first derivative (but still produce discontinuities in the second derivative). I consulted a book from the company library to find such an interpolation method. I found a reference to Hermite interpolation, a non-linear interpolation method between two points at which are tabulated both the functional value, and the slope (first derivative), which does indeed enforce continuity of both at the end-points. Since we did not have the slope tabulated, I inserted the difference of the two adjacent points divided-by-two for the tabulated slope at the two end-points, and collected terms to produce a 4-point interpolation formula that I labelled Hermite interpolation with approximate slope. Just as bi-linear interpolation is a generalisation of linear interpolation in 1 dimension to interpolation in 2 dimensions, this too can be generalized to 2 dimensions by doing 4 interpolations in X on parallel rows followed by a single interpolation in Y on the resulting column. But 20 multiply-accumulate operations to calculate the correction, plus more to add in the uncorrected address, would take more time than the minimum arrival time between events. So I made an approximation to save time. Instead I did linear interpolation in X on the outer 2 rows, Hermit interpolation on the inner 2 rows, and a final Hermite interpolation in Y on the results in X, saving 4 operations, so it fit into the allowable time. I presented this idea and was given the permission to proceed. First I tested it in simulation in 2 stages. For the first simulation I wrote 64bit fixed-point arithmetic subroutines so that I could calculate the result without any intermediate rounding, though there was a final rounding at the end, to test the algorithm. For input I used a real correction table from the calibration of a real system, and a captured raw image from the same system prior to correction, the same data presented at the group meeting to demonstrate the problem. The simulation was run, and the corrected image was output onto X-ray film at a much higher resolution than a printer can print on paper. The film was developed and examined, the edge artifacts were gone. This proved both that the interpolation method worked, and that my approximation to save time had not compromised the result enough to cause artifacts. After designing the real data path, I modified the simulation to reflect the real resolution of the MAC, and to include rounding of intermediate results. This second stage simulation was run to verify the proposed data path. Again all artifacts were absent. Then, I completed the schematic design of my linearity correction board. This was in the mid-1980s so the DSP portion of the data path was built with a MAC, a separate register-file IC to store intermediate values, a preprogrammed EPROM to hold the interpolation coefficients (I wrote a C program to calculate the coefficients and make a S-record file to be used in the EPROM programmer), SRAM for the correction tables, and buffers to connect the different buses. This was duplicated to process the X and Y portions of the correction vector in parallel. The finite state machine that controlled the DSP was in a PAL. The board was built and successfully replaced the earlier linearity correction board that used bilinear interpolation. In the end, two versions of the board were designed, one as part of a retrofit package to upgrade existing cameras, and the other as part of a design for a new camera. A patent was later granted for this work, United States Patent # 4,808,826 "Smooth dot density spatial distortion correction in photon imaging devices." I shared the patent with others working on the design of the retrofit package, including hardware engineers and software engineers. Tim R. Johnson is an electrical engineer with 29+ years experience in the design of digital hardware and supporting software for different industries: medical instrumentation, industrial controls, data acquisition and computer systems. He has an MSEE from CWRU, and a BSEE from MIT. He is currently looking for a new position. He submitted this article as part of Frankenstein's Fix, a design contest hosted by EE Times (US).  

I was then working at a medical imaging company involved in Nuclear Medicine product development. The product was a scintillation camera, or gamma camera, used to image gamma radiation-emitting radioisotopes. The patient was given a radioactive-tagged pharmaceutical that was preferentially absorbed by the area of the body being studied. The gamma rays given off were received by a detector head, which outputted the X-Y position and energy of each photon received. These 3 signals were sampled at 14bit resolution. However, the data required 3 stages of correction to produce a usable image. In linearity correction, a correction vector is read from a stored table addressed by the observed X-Y position and added to it to produce the corrected X-Y position. Since storing a complete correction table at 14 bit x 14 bit resolution was impracticable, the correction tables were stored at 7 bit x 7 bit resolution and bi-linear interpolation was used to interpolate from the stored table. In a flood test with a linearity board using bi-linear interpolation, image artifacts were found, edges at interpolation cell boundaries in what should have been a uniform field after correction. This was brought up at a group meeting and all of us were asked to consider a solution. I remembered from an image processing class that the human visual system is sensitive to edges, and that edges are characterized as abrupt changes in the first derivative in space of an image. Bi-linear interpolation enforces continuity of the value of a function at cell boundaries, but it produces a discontinuity in the first derivative. I reasoned that such a discontinuity would produce the edge artifacts seen, so what was needed was an improved interpolation method that would enforce continuity at the cell boundaries in both the functional value and the first derivative (but still produce discontinuities in the second derivative). I consulted a book from the company library to find such an interpolation method. I found a reference to Hermite interpolation, a non-linear interpolation method between two points at which are tabulated both the functional value, and the slope (first derivative), which does indeed enforce continuity of both at the end-points. Since we did not have the slope tabulated, I inserted the difference of the two adjacent points divided-by-two for the tabulated slope at the two end-points, and collected terms to produce a 4-point interpolation formula that I labelled Hermite interpolation with approximate slope. Just as bi-linear interpolation is a generalisation of linear interpolation in 1 dimension to interpolation in 2 dimensions, this too can be generalized to 2 dimensions by doing 4 interpolations in X on parallel rows followed by a single interpolation in Y on the resulting column. But 20 multiply-accumulate operations to calculate the correction, plus more to add in the uncorrected address, would take more time than the minimum arrival time between events. So I made an approximation to save time. Instead I did linear interpolation in X on the outer 2 rows, Hermit interpolation on the inner 2 rows, and a final Hermite interpolation in Y on the results in X, saving 4 operations, so it fit into the allowable time. I presented this idea and was given the permission to proceed. First I tested it in simulation in 2 stages. For the first simulation I wrote 64bit fixed-point arithmetic subroutines so that I could calculate the result without any intermediate rounding, though there was a final rounding at the end, to test the algorithm. For input I used a real correction table from the calibration of a real system, and a captured raw image from the same system prior to correction, the same data presented at the group meeting to demonstrate the problem. The simulation was run, and the corrected image was output onto X-ray film at a much higher resolution than a printer can print on paper. The film was developed and examined, the edge artifacts were gone. This proved both that the interpolation method worked, and that my approximation to save time had not compromised the result enough to cause artifacts. After designing the real data path, I modified the simulation to reflect the real resolution of the MAC, and to include rounding of intermediate results. This second stage simulation was run to verify the proposed data path. Again all artifacts were absent. Then, I completed the schematic design of my linearity correction board. This was in the mid-1980s so the DSP portion of the data path was built with a MAC, a separate register-file IC to store intermediate values, a preprogrammed EPROM to hold the interpolation coefficients (I wrote a C program to calculate the coefficients and make a S-record file to be used in the EPROM programmer), SRAM for the correction tables, and buffers to connect the different buses. This was duplicated to process the X and Y portions of the correction vector in parallel. The finite state machine that controlled the DSP was in a PAL. The board was built and successfully replaced the earlier linearity correction board that used bilinear interpolation. In the end, two versions of the board were designed, one as part of a retrofit package to upgrade existing cameras, and the other as part of a design for a new camera. A patent was later granted for this work, United States Patent # 4,808,826 "Smooth dot density spatial distortion correction in photon imaging devices." I shared the patent with others working on the design of the retrofit package, including hardware engineers and software engineers. Tim R. Johnson is an electrical engineer with 29+ years experience in the design of digital hardware and supporting software for different industries: medical instrumentation, industrial controls, data acquisition and computer systems. He has an MSEE from CWRU, and a BSEE from MIT. He is currently looking for a new position. He submitted this article as part of Frankenstein's Fix, a design contest hosted by EE Times (US).

Typically, medical devices are not supposed to smoke. You don't have to be the United States' Surgeon General to realise this. Early in my career, I was a newly hired engineer at a large medical device company. The first week my manager, Bernie, gave me full responsibility for supporting an existing product. I'll call it the Smoko-2. In my first week, I was invited to a "tear-down" session on the Smoko-2. The meeting started out great—the lead mechanical engineer praised the design, which used just one exposed screw to hold together the case and circuit boards. Things are looking rosy. People are smiling. Even the young ladies who assembled the units on the production line are smiling. Bernie himself isn't sweating and fidgeting as much as usual. Life was good. Then things turn ugly. One of the more experienced women on the repair line says, "Oh yeah, but we do get back some Smokos with melted and smoldering power cords." You could see the enthusiasm leak out of the room. I look around and the other engineers and managers look as bewildered as I am. Nice how they spring this on us at a very public meeting! There wasn't much sparkle or eye contact after that bombshell and the meeting quickly winds down. Bernie's forehead is glistening. He's playing the imaginary drums with two pencils. The discussion peters out to random monosyllables and the group quickly disperses, with some of us on the engineering team slinking away quietly as if hoping we're invisible. As the new engineer, I get the hairy eyeball from Bernie, and I don't need any further impetus. I go to pull the main Smoko-2.pdf drawing, and I see the problem right away. "Hmm, how did this ever happen?" I ask myself. The design required 9V at up to 2 amps be sent through a connector with 15 pins rated only at 1.5 amps each. So no problem, right? Since only 9 pins are needed for data, the designer allocated the remaining pins as follows: three to carry plus, three to carry minus. That is absolutely okay, in the theoretical plane. Plenty of current capability, 4.5 amps theoretical, 2 amps actual, a huge safety margin you think, sitting on your theoretical cloud. But in reality, this decision is a disaster waiting to happen. The connector mostly relies on gravity, the weight of the device on its charging stand, to make firm contact. And it expects the connector pins to be clean and perfectly straight and the device and base to be exactly perpendicular. None of these situations happen in the real world. Emergency rooms can be hectic, devices are not always carefully set down perpendicular into their chargers, and bits of crud and cleaning fluids can get into things. All it takes is a speck of a foreign object to interfere, and then we have 2 amps trying to go through not three pins, but maybe just two or even one. Push 2 amps through a 1.5 amp contact, maybe add a little smudge of medical salve or a speck of bandage cotton, and we have Smoke City, Utah. Bad show. At $880 for each Smoko-2, customers would expect it to not smolder. In an ideal world we would just redesign the whole thing—but that would be a huge deal—there is a real shortage of off-the-shelf connectors with nine or so data lines plus two heftier power lines. We might have to get a custom connector designed, new cases and charging stands and circuit boards and user guides made up, plus FDA clinical trials, easily a quarter-million dollar and year-long project. And we'd have to recall all the devices in use, a many-million-dollar hit. And the nice people on the production line will not be smiling at me in the future as they'd have to increase their build rate 20-fold to replace all the units out in the field. And poor me, I've been here two weeks and I have to tell my manager that "my" device needs a couple of million dollars in bandaging. I was downcast for several days, even considering going back to my first job, shoveling coal into a greenhouse boiler. While dirtier, it was nice warm work, and even if the worst happened and the boiler exploded, it wouldn't hurt as much as having to run through the view-graphs in front of the managers, especially the bar chart showing $2M of unplanned expenditures on my project. When a boiler explosion starts sounding like a good thing, you know you're in a pretty dark place. Fortunately, our dog Beau came to the rescue. He needs frequent walks to empty his output queue, if you know what I mean. During one of these long walks when I had plenty of time to think, an idea popped into my mind. No, not a perfect solution, but keeping with the medical genre, a band-aid, inexpensive, and just good enough to work. As luck would have it, there was just enough room inside the power connector to put a simple CMOS Schmitt-trigger to sense power abnormalities and a flip-flop to shut down the power. Another Schmitt-trigger could be coerced to act like an astable pulse generator, trying to turn on the flip-flop every few seconds to retry the power-on situation. Not a perfect solution, but one good enough to prevent major smoldering and a multi-million dollar recall. Bernie gave his go-ahead, I got to keep my job, C. Everett Koop stopped appearing in my dreams, I got a good job review six months later, and lived happily ever after. Well, until the next debacle. This story was submitted by George Gonzalez for Frankenstein's Fix, a design contest hosted by EE Times (US). George Gonzalez is by day, officially, a Software Guru, using his ancient degree in Computer Science, plus 35 years of experience, stirring up commercially useful mixtures of C, Delphi, Python, and assembly language. While his father and brother are both accomplished EE's, George just attacks hardware with some general principles learned at the school of hard knocks (and with safety glasses). At home George fawns over and repairs old tube radios from the 30s thru the 60s. At work, when there is no software to do, he is occasionally allowed to use his instincts to keep somewhat less ancient (designed in 1995) products in production.

Generally, medical devices should not smoke. You don't have to be the United States' Surgeon General to realise this. Early in my career, I was a newly hired engineer at a large medical device company. The first week my manager, Bernie, gave me full responsibility for supporting an existing product. I'll call it the Smoko-2. In my first week, I was invited to a "tear-down" session on the Smoko-2. The meeting started out great—the lead mechanical engineer praised the design, which used just one exposed screw to hold together the case and circuit boards. Things are looking rosy. People are smiling. Even the young ladies who assembled the units on the production line are smiling. Bernie himself isn't sweating and fidgeting as much as usual. Life was good. Then things turn ugly. One of the more experienced women on the repair line says, "Oh yeah, but we do get back some Smokos with melted and smoldering power cords." You could see the enthusiasm leak out of the room. I look around and the other engineers and managers look as bewildered as I am. Nice how they spring this on us at a very public meeting! There wasn't much sparkle or eye contact after that bombshell and the meeting quickly winds down. Bernie's forehead is glistening. He's playing the imaginary drums with two pencils. The discussion peters out to random monosyllables and the group quickly disperses, with some of us on the engineering team slinking away quietly as if hoping we're invisible. As the new engineer, I get the hairy eyeball from Bernie, and I don't need any further impetus. I go to pull the main Smoko-2.pdf drawing, and I see the problem right away. "Hmm, how did this ever happen?" I ask myself. The design required 9V at up to 2 amps be sent through a connector with 15 pins rated only at 1.5 amps each. So no problem, right? Since only 9 pins are needed for data, the designer allocated the remaining pins as follows: three to carry plus, three to carry minus. That is absolutely okay, in the theoretical plane. Plenty of current capability, 4.5 amps theoretical, 2 amps actual, a huge safety margin you think, sitting on your theoretical cloud. But in reality, this decision is a disaster waiting to happen. The connector mostly relies on gravity, the weight of the device on its charging stand, to make firm contact. And it expects the connector pins to be clean and perfectly straight and the device and base to be exactly perpendicular. None of these situations happen in the real world. Emergency rooms can be hectic, devices are not always carefully set down perpendicular into their chargers, and bits of crud and cleaning fluids can get into things. All it takes is a speck of a foreign object to interfere, and then we have 2 amps trying to go through not three pins, but maybe just two or even one. Push 2 amps through a 1.5 amp contact, maybe add a little smudge of medical salve or a speck of bandage cotton, and we have Smoke City, Utah. Bad show. At $880 for each Smoko-2, customers would expect it to not smolder. In an ideal world we would just redesign the whole thing—but that would be a huge deal—there is a real shortage of off-the-shelf connectors with nine or so data lines plus two heftier power lines. We might have to get a custom connector designed, new cases and charging stands and circuit boards and user guides made up, plus FDA clinical trials, easily a quarter-million dollar and year-long project. And we'd have to recall all the devices in use, a many-million-dollar hit. And the nice people on the production line will not be smiling at me in the future as they'd have to increase their build rate 20-fold to replace all the units out in the field. And poor me, I've been here two weeks and I have to tell my manager that "my" device needs a couple of million dollars in bandaging. I was downcast for several days, even considering going back to my first job, shoveling coal into a greenhouse boiler. While dirtier, it was nice warm work, and even if the worst happened and the boiler exploded, it wouldn't hurt as much as having to run through the view-graphs in front of the managers, especially the bar chart showing $2M of unplanned expenditures on my project. When a boiler explosion starts sounding like a good thing, you know you're in a pretty dark place. Fortunately, our dog Beau came to the rescue. He needs frequent walks to empty his output queue, if you know what I mean. During one of these long walks when I had plenty of time to think, an idea popped into my mind. No, not a perfect solution, but keeping with the medical genre, a band-aid, inexpensive, and just good enough to work. As luck would have it, there was just enough room inside the power connector to put a simple CMOS Schmitt-trigger to sense power abnormalities and a flip-flop to shut down the power. Another Schmitt-trigger could be coerced to act like an astable pulse generator, trying to turn on the flip-flop every few seconds to retry the power-on situation. Not a perfect solution, but one good enough to prevent major smoldering and a multi-million dollar recall. Bernie gave his go-ahead, I got to keep my job, C. Everett Koop stopped appearing in my dreams, I got a good job review six months later, and lived happily ever after. Well, until the next debacle. This story was submitted by George Gonzalez for Frankenstein's Fix, a design contest hosted by EE Times (US). George Gonzalez is by day, officially, a Software Guru, using his ancient degree in Computer Science, plus 35 years of experience, stirring up commercially useful mixtures of C, Delphi, Python, and assembly language. While his father and brother are both accomplished EE's, George just attacks hardware with some general principles learned at the school of hard knocks (and with safety glasses). At home George fawns over and repairs old tube radios from the 30s thru the 60s. At work, when there is no software to do, he is occasionally allowed to use his instincts to keep somewhat less ancient (designed in 1995) products in production.