Advocacy openhardware

Another device is the medical devices themselves. We need open hardware implementations of these so that we can run them in qemu or similar emulators along side our current therapy. The analysis of deviations between the observations of simulated therapy emulated in our tools (the predicted behavior of the pump), and the observed therapy (our analysis of the raw data) can be compared with the vendor's analysis of the raw data at whim.

Used to prep for comment on http://www.healthit.gov/buzz-blog/privacy-and-security-of-ehrs/patient-access-to-their-health-information/

On Fri, Jul 27, 2012 at 12:44 PM, Benjamin West [email protected] wrote:

I guess the interesting question for open source, and for society is: Will the open principles we take for granted in the architecture of the web and internet also apply to the internet of things that is coming? Most devices in the web of things that exists today are locked behind walls, because they are old and lack connectivity. No one but the vendor knows how to debug or audit the behavior of too many devices, not just medical.

-bewest

On Fri, Jul 27, 2012 at 12:09 PM, Benjamin West [email protected] wrote:

[...on data brokers ... ] would like to produce such a device in some kind of case study. Would be cool to see a bunch of authors across the whole stack document how to solve a civic and social issues using open source by demonstration. [ ... on commenting on ... ] Adrian, I love the link you posted about data brokers, but I haven't had enough time to study the issue well enough to develop a more thoughtful comment than +1 or to think through possible side-effects.

-bewest

On Fri, Jul 27, 2012 at 11:52 AM, Benjamin West [email protected] wrote:

TL;DR, my guiding principle here is from the making of Star Wars. In the future most extent things are old.

-bewest

Edit: I'm aware of open embedded and lots of similar projects. There is yet! to be a set of tools to emulate medical devices, or trivialize fetching data from any device with USB or RS232 connectivity, which could be used to precisely observe therapy among other things.

On Fri, Jul 27, 2012 at 11:15 AM, Benjamin West [email protected] wrote:

Curated unconference. Ok, I'm planning on going. I believe there is lots to discuss with these people. When viewing our problems from a birds eye view, I've tried to find a way to look at solutions that are [or can be made] accessible to people far beyond my immediate uses. I believe this group will share enough use cases to help advance the technology.

I've also found that small pieces of technology that are simple and only do one thing well means that there are lots of pieces of technology. While this allows different types of experts to easily jump in to improve the things they know about with minimum overhead, it also means that there are lots of bits of technology capable of working together and that to achieve complicated results, we will depend on subtle side-effects of how some of those components interact. It also means a lot of work. I have been somewhat disengenous in claiming how simple everything is. When viewed in isolation, no component is especially complicated, but the gestalt effect of glueing all these lego blocks together makes the system as a whole very complicated.

Right now, there are many missing pieces. However, I believe these people share our need to establish a trivially working toolchain that makes working on open devices easy. Our common need with them is that there are lots of devices using thousands of custom protocols that have all kinds of data about us. This data can be used in amazing ways, but we need access to it first, and we need to commodotize access to it in order to provide a robust and sane platform for dealing with all the kinds of new data we will add. My proposal is a device that establishes an independent "data-bus" or "data broker." It can establish an internet connection to a tcp server of choosing, and then establish a direct connection from the software running on the server to a peripheral device containing useful data attached to our device.

This solution can be re-used to customize these automated brokering agents. Actually I call them unapi, or unapies, at the moment, because they are a Unversal Network Adapter implemented by a rasperrypi. We are also targetting H8, arduino, and android. The use of android opens development to almost everyone who has an android phone or tablet and puts it squarely in the hot spot of where active development happens. However, pursuing and open hardware route while keeping the scope of features fairly narrow will allow for greater pay off. Part of the idea is to eventually enable use of software defined radios, which would allow these devices to dynamically switch between 2G, 3G, LTE, and wireles, and would enable using GPS using the same piece of hardware. However, this idea is kind of a funny way of scoping the problem, when most believe idea of keeping it simple is to put everything they want to do in the smallest package that will get the job done. My solution relies on smaller pieces of technology developed in parallel, and this sometimes produces pushback from engineers when I use this approach elsewhere, but it is familiar in the open source world.

Easily customized variants of this device could be used to do an incredible range of things: one time, zero-touch installation in car, sneakers, glucose meters, weight scales, coffee grinders, coffee makers, blood pressure monitors, tvs. The really exciting bits come when variants of these devices are paired with other wireless modules: so for example we talked about the idea of base stations that would sit plugged into the wall that could be paired with other variants of these wireless devices for mobile use. I actually found a rough implementation of this generic device using the specific hardware my insulin pump uses! http://geodenx.blogspot.com/p/h8nic.html

This scoping of the technology keeps an open device project or an android project still relatively small enough to consider participating in, but useful enough to matter to lots of people. I think.

Anyway, I think it'd be cool to get a session on open hardware and open software approaches to commoditize data access and provide the kind of open source data brokers Adrian linked to in his argument. I'm not sure who attends these conferences? How many of them are involved in technical projects? What are they willing to engage in?

-bewest