Archive for the ‘Open Source’ Category

When Open-source can Kill or Cure

Wednesday, June 6th, 2012

The use of open-source software in medical devices has been a topic of discussion for many years. The Economist article Open-source medical devices: When code can kill or cure highlights continuing activity in the academic community and interest by the FDA in developing processes around its use.

One of the big unknowns in this area is how a community might be formed (Dreaming of Flexible, Simple, Sloppy, Tolerant in Healthcare IT  has some thoughts on this).

From the article:

Eventually, medical devices might evolve into collections of specialised (and possibly proprietary) accessories, with the primary computing and safety features managed by an open-source hub.

This is in reference to both hardware and software, but in either case one major challenge will be how to incentivize contributions.  Open-source means free to use and modify. If there is no financial gain to be had, other benefits for contributing need to be developed.  Also, proprietary and open-source in the same sentence seems like an oxymoron, so I'm not sure how that's going to work.

Another barrier would be liability risk. Let's say you contributed software to this hub and that component ended up in a device that harmed or killed someone.  All of the legal waivers, disclaimers, and releases in world wouldn't necessarily keep you out of a court room.

I don't think the basic arguments discussed in Open Source Medical Device Connectivity have changed a great deal.  At the end of the day the medical device manufacturer will ultimately be responsible for ensuring the safety and efficacy of their device.

Plunging into Web Development

Sunday, June 7th, 2009

ConanI've authored a few web sites. Nothing professionally though. I know just enough HTML, CSS, and JavaScript to be dangerous.

Now I'm faced with creating a customer-facing site that has (or will someday soon have) real requirements.

Here are a couple of the requirements I know so far:

  1. Relatively low volume traffic. The site will be public, but only registered users (customers) will have access.  No product pages, no shopping carts, no ads, no social networking. The front page is a login screen.
  2. Reliable and secure transport and storage of medical data.  At a minimum we must comply with HIPAA standards (privacy rules).

I don't see web site development as really that different from building any other type of application. It's all software. The architectural building blocks may be different, but the developer's mind-set and methodologies for producing a quality product need to  be the same.

I haven't gotten far enough along to really understand all of the deployment and maintenance issues. I'm thinking about them though. The same goes for testing. I can foresee development vs. production platform testing issues that will have to be carefully considered.

What I want to do is walk you through my rational for the selection of some of the major components and tools I'm considering using for this project.

Web Frameworks

Here's a little historical perspective on selecting a web development framework:

choosingwebframework

Yep, that's how it feels.  There are at least 100 options (plus a couple of my additions):

AgaviAIDA/Web | Ajile | Akelos | Apache ClickApache CocoonApache StrutsApache WicketAppFuseAraneaASP.NET MVC | Axiom Stack | BFCCakePHPCampingCatalystCherryPyCodeIgniterColdSpringCSLACppCMSDjangoDotNetNukeDrupal | ErlyWeb | eZ ComponentsFlex | FUSE | FuseboxGoogle Web ToolkitGrokGrailsHamletsHordeInterchangeItsNatIT Mill ToolkitJavaServer Faces | Jaxer | JBoss SeamKepler | Kohana | Lift | LISA | ManyDesigns PortofinoMasonMaypoleMach-IIMerbMidgardModel-GlueMonoRailMorfikNitroonTapOpenACSOpenLaszloOpenXava | Orbit | PEAR | Orinoco | PyjamasPylonsQcodoRadicoreReasonable Server FacesRIFERuby on RailsSeasideShale | Simplicity | SilverStripe (Sapphire)SmartClientSofiaSPIPSpringStripesSymfonyTapestryThinWire | Tigermouse | VaadinTurboGearsWavemakerweb2pyWebObjectsWebWork | Wigbi | YiiZendZK | Zoop | Zope 2Zope 3ztemplates

YIKES!!

As a .NET developer, my first inclination was to look at ASP.NET MVC. The two most popular and active open source frameworks are  Ruby on Rails (RoR) and Django (Python-based). To be honest, I have not spent a lot of time investigating any of the others.

Why is it that I often find myself in this situation? It's usually not 100, but there always seems to be multiple well developed solutions for these types of problems.  I ran into the same thing a couple of years ago when I was selecting an ORM for a .NET project.

All you can do is start by taking the advice of others ("most popular") and give one or two a try.  Not only will you get a good sense of how well the framework meets your project requirements, since there will inevitably be problems or questions you'll also be able to evaluate documentation and community activity.

It's like making pasta -- you throw a noodle against the wall and if it sticks, you're done cooking.  Well, not really... but you know what I mean.

Hosting

One of the major considerations is hosting. I've previously explored the three major cloud computing platforms.

  • Amazon EC2 would be overkill (see requirement #1). I don't see a need for significant scale-up in the foreseeable future. Running a small on-demand EC2 instance 24/7 is more expensive (~$70/month) than just buying hosted services.  Also, supporting a complete OS platform is unnecessary work.
  • Microsoft Azure is currently in CTP (Community Technology Preview) and it's still unclear what the pricing will be.
  • That leaves Google App Engine.  Based on the GAE Quotas, we would be able to operate under the limits for quite a while (exceeding the quotas would be a good thing).  That means GAE can provide us free hosting, which is hard to beat.

There are literally 100's of hosting options, and most would meet our bandwidth and storage requirements at a nominal cost.  Independent of storage (see below) I guess I'm biased towards a cloud solution for two reasons:

  1. "Good Enough" isn't Good Enough: I've been hosting this domain on a commercial site for about 6 years.  I'd classify my host as good enough for my personal use (family site, photo gallery, this blog, etc.).  If my hosting service went away tomorrow, no big deal. I backup everything regularly and could be up and running on a comparable host pretty quickly. But for business purposes that involve critical customer medical data, "good enough" and the possibility of the host disappearing just doesn't cut it.
  2. Large Infrastructure: This is what makes a cloud solution so attractive. With any of the three cloud options you are buying into reliability and stability. They already have multiple data centers, security, and disaster plans in place.  You don't have to worry about Amazon, Microsoft, or Google going away any time soon. Unless you have the resources to build it yourself, IMO using a cloud service is a good business decision.

So for now I'll be using Google App Engine.

Data Storage

Now lets looks at requirement #2: reliable and secure data storage. At this time the best solution seems to be Amazon S3. Amazon has already put a lot of thought into this:  Creating HIPAA-Compliant Medical Data Applications with Amazon Web Services (warning: PDF).  S3 transfer and storage costs are very reasonable.  Paying only for what you use is a real benefit.

Both Google and Microsoft are very active in the Healthcare sector (Google Health and HealthVault) and I'm sure will soon have cloud storage offerings with similar features.

There are a number of web hosting sites that claim HIPAA data storage compliance, but most seem to just be using "HIPAA" as a marketing tool to attract medically related clients. I'd stay away from these.

Web Frameworks (part 2)

Deciding to use GAE quickly narrows the web framework choice down. GAE supports Python (w/ Django) and the Java 6 runtime environment. I do not believe that either ASP.NET or RoR are supported on GAE. Done deal -- Django.

I know what you're thinking.  There are many other Python-based web frameworks and even Java alternatives that I should be considering. That's true, but Django is arguably the most popular and has a very active developers community. Also, there are several Google Code App Engine projects (see below) that support Django integration.

I did play around with RoR . The Ruby language itself is great. I love having five different ways to do the same thing. The RoR web framework is mature and has many of the same features as Django.

I looked at ASP.NET MVC, but only from a distance. Here's a concise take from someone that recently jumped in: ASP.NET MVC Impressions after 1 week.

Development Environment

I initially setup a Windows-based Python/Django/GAE-SDK development environment but found it to be too clumsy.  I've settled into Ubuntu 9.04 running in a VirtualBox VM.

The Ubuntu Package Manager handled installation of all the necessary prerequisite components. Now that I think of it, I didn't have to do a single ./configure and make. That's progress!

I'm an old Unix hack and I quickly fell back into my first love : Emacs. After the nostalgia wore off, I needed to find a real development IDE.  There were two choices:

  1. Eclipse:  I tried using the PyDev plug-in along with some Django integration instructions I found. Google also provides some Eclipse integration, but being able to start the server and other functions from the IDE was not that important to me.  I'd rather use the command line. Also, Eclipse just seems like a real dog.
  2. Netbeans:  With the Python plug-in Netbeans works fine, so I'll stick with it until something better comes along.

Django (Front-end)

The four features that make  Django attractive:

  • Object-relational mapper: Define your data models entirely in Python. You get a rich, dynamic database-access API for free — but you can still write SQL if needed.
  • Automatic admin interface: Save yourself the tedious work of creating interfaces for people to add and update content. Django does that automatically, and it's production-ready.
  • Elegant URL design: Design pretty, cruft-free URLs with no framework-specific limitations. Be as flexible as you like.
  • Template system: Use Django's powerful, extensible and designer-friendly template language to separate design, content and Python code.

Carefully walk through the four part Django tutorial. Beware: there are three versions of the tutorial (0.96, 1.0, and "Latest"). Make sure you're using the desired one.

For Django integration with GAE I'm using app-engine-patch.  I had first tried Google App Engine Helper for Django, but I found that app-engine-patch works much better.

Data Integration (Back-end)

Getting data to and from the S3 server will be a critical component.  I have only started looking into this, but the Amazon documentation seems very good.  The Getting Started Guide examples are presented in multiple languages (PHP, C#, Java, Perl, Ruby, Python).  A Python interface to Amazon Web Services, Boto, also looks like it might be useful.

Amazon S3 POST is an efficient way to move data to S3:

S3 Post

The back-end will require much more investigation.

For the additional database needs (account management, logging, auditing, etc.) I'll just use the GAE Datastore.

Overwhelmed

There's a lot of "stuff" here. Investigating and evaluating it all plus making decisions is a daunting process.

The purpose of going through these selections is to reduce the number of variables so I could start concentrating on an architecture and design that will meet project requirements. There are still many unknowns though, and I'm sure there will be major bumps in the road that will cause me to change direction.

UPDATE (11/21/2010): Beware -- you get what you pay for!: Goodbye Google App Engine (GAE)

Interoperability: Google Protocol Buffers vs. XML

Monday, July 14th, 2008

Google recently open sourced Protocol Buffers: Google's Data Interchange Format (documentation, code download). What are Protocol Buffers?

Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler.

The documentation is complete and worth a quick read through. A complete analysis of PB vs. XML can be found here:  So You Say You Want to Kill XML.....

As discussed, one of the biggest drawbacks for us .NET developers is that there is no support for the  .NET platform. That aside, all of the issues examined are at the crux of why interoperability is so difficult. Here are some key points from the Neward post:

  1. The advantage to the XML approach, of course, is that it provides a degree of flexibility; the advantage of the Protocol Buffer approach is that the code to produce and consume the elements can be much simpler, and therefore, faster.
  2. The Protocol Buffer scheme assumes working with a stream-based (which usually means file-based) storage style for when Protocol Buffers are used as a storage mechanism. ... This gets us into the long and involved discussion around object databases.
  3. Anything that relies on a shared definition file that is used for code-generation purposes, what I often call The Myth of the One True Schema. Assuming a developer creates a working .proto/.idl/.wsdl definition, and two companies agree on it, what happens when one side wants to evolve or change that definition? Who gets to decide the evolutionary progress of that file?

Anyone that has considered using a "standard" has had to grapple with these types of issues. All standards gain their generality by having to trade-off for something (speed, size, etc.). This is why most developers choose to build proprietary systems that meet their specific internal needs. For internal purposes, there's generally not a need to compromise. PB is a good example of this.

This also seems to be true in the medical device industry.  Within our product architectures we build components to best meet our customer requirements without regard for the outside world. Interfacing with others (interoperability) is generally a completely separate task, if not a product unto itself.

Interoperability is about creating standards which means having to compromise and make trade-offs.  It would be nice if Healthcare interoperability could be just a technical discussion like the PB vs. XML debate. This would allow better integration of standards directly into products so that there would be less of the current split-personality (internal vs. external  needs) development mentality.

Another thing I noticed about the PB announcement -- how quickly it was held up to XML as a competing standard. With Google's clout, simply giving it away creates a de facto standard. Within the medical connectivity world though, there is no Google.

I've talked about this before, but I'm going to say it again anyway. From my medical device perspective, with so many confusing standards and competing implementations the decision on what to use ends up not being based on technical issues at all. It's all about picking the right N partners for your market of interest, which translates into N (or more) interface implementations. This isn't just wasteful, it's also wrong. Unfortunately, I don't see a solution to this situation coming in the near future.

One Reason Why Linux Isn’t Mainstream: ./configure and make

Sunday, June 22nd, 2008

Bare with me, I'll get to the point of the title by the end of the post.

I primarily develop for Microsoft platform targets, so I have a lot of familiarity with Microsoft development tools and operating systems. I also work with Linux-based systems, but mostly on the systems administration side: maintaining servers for R&D tools like Trac and Subversion.

I recently had some interest in trying to use Mono running on Linux as .NET development platform.

This also allowed me to try Microsoft Virtual PC 2007 (SP1) on XP-SP3. I went to a local .NET Developer's Group (here) meeting a couple of weeks ago on Virtual PC technology. Being a Microsoft group most of the discussion was on running Microsoft OS's, but I saw the potential for using VPC running Linux for cross-platform development. My PC is an older Pentium D dual core without virtualization support, but it has 3Gig of RAM and plenty of hard disk space, so I thought I'd give it a try.

Download and installation of Ubuntu 8.04 (Hardy Heron) LTS Desktop on VPC-2007 is a little quirky, but there are many blog posts that detail what it takes to create a stable system: e.g. Installing Ubuntu 8.04 under Microsoft Virtual PC 2007. Other system optimizations and fixes are easily found, particularly on the Ubuntu Forums.

OK, so now I have a fresh Linux installation and my goal is to install a Mono development environment. I started off by following the instructions in the Ubuntu section from the Mono Other Downloads page. The base Ubuntu Mono installation does not include development tools. From some reading I found that I also had to install the compilers:

# apt-get install mono-mcs
# apt-get install mono-gmcs

So now I move on to MonoDevelop. Here's what the download page looks like:

Monodevelop Download

Here's my first gripe: Why do I have to download and install four other dependencies (not including the Mono compiler dependency that's not even mentioned here)?

Second gripe: All of the packages require unpacking, going to a shell prompt, changing to the unpack directory, and running the dreaded:

./configure
make

Also notice the line: "Compiling the following order will yield the most favorable response." What does that mean?

So I download Mono.Addins 0.3, unpack it, and run ./configure. Here's what I get:

configure: error: No al tool found. You need to install either the mono or .Net SDK.

This is as far as I've gotten. I'm sure there's a solution for this. I know I either forgot to install something or made a stupid error somewhere along the way. Until I spend the time searching through forums and blogs to figure it out, I'm dead in the water.

I'm not trying to single out the Mono project here. If you've even tried to install a Unix application or library you inevitably end up in dependency hell -- having to install a series of other packages that in turn require some other dependency to be installed.

So, to the point of this post: There's a lot of talk about why Linux, which is free, isn't more widely adopted on the desktop. Ubuntu is a great product -- the UI is intuitive, system administration isn't any worse than Windows, and all the productivity tools you need are available.

In my opinion, one reason is ./configure and make. If the open source community wants more developers for creating innovative software applications that will attract a wider user base, these have to go. I'm sure that the experience I've described here has turned away many developers.

Microsoft has their problems, but they have the distinct advantage of being able to provide a complete set of proprietary software along with excellent development tools (Visual Studio with ReSharper is hard to beat). Install them, and you're creating and deploying applications instantly.

The first step to improving Linux adoption has to be making it easier for developers to simply get started.

100 Open Source Software Tools for Medical Professionals

Wednesday, April 16th, 2008

I mentioned an Open Source Medical Software list before. Here's yet another list:

The Top 100 Open Source Software Tools for Medical Professionals

The contents of this one provide a broader selection of functionality. Annotated lists like these are a great resource.

Hat tip: The Healthcare IT Guy

Open Source Medical Software

Monday, January 21st, 2008

Free Medical Software appears to be a comprehensive list that's currently being kept up-to-date (hat tip: LinuxMedNews). The project attributes and annotations make the list quite useful. Nice job Holger!

EHR System Modeling

Tuesday, January 1st, 2008

I'm a regular Slashdot reader and it's rare to come across a health care related post. So Arguing For Open Electronic Health Records of course caught my eye. I'm sure it was the open standards aspect that attracted them, but I also wanted to point out why the use of software modeling is so important to the development of EHRs.

The Tim Cook post is interesting in several respects.

The first is the reiteration of the importance of the "lack of true interoperability standards" and its affect on adoption of EMR. I've talked about this numerous times.

Another important point is that even though open source licensing may be free, the real costs of implementing any EHR system (i.e. going paperless) are significant.

The importance of understanding and communicating the "semantic context" of patient data is also a key concept.

The goal of the openEHR open-source project is to provide a model and specifications that capture patient data without loss of semantic context. A "two-level modeling" approach is used (from here):

Two-Level Software Engineering
(click on the image to see it at full resolution)

Within this process, IT developers concentrate on generic components such as data management and interoperability, while groups of domain experts work outside the software development process, generating definitions that are used by systems at runtime.

If you've done any work with Microsoft's WPF, this model should look familiar. Separation of responsibilities (designer vs. developer) is one of the fundamental shifts in GUI development that XAML provides. Separating the domain experts from the developers when building a health care IT system is also clearly beneficial.

No matter how good the openEHR model is, it unfortunately has the same adoption problems as many other health care interoperability systems: competing "standards". For example, HL7 V3 Reference Information Model (RIM) and CEN 13606 have the same goals as openEHR.

Developing software systems based on conceptual models of the real world is not new. For example, the OMG Model-driven Architecture (MDA, also see here):

These platform-independent models document the business functionality and behavior of an application separate from the technology-specific code that implements it, insulating the core of the application from technology and its relentless churn cycle while enabling interoperability both within and across platform boundaries.

These types of systems not only provide separation of responsibilities but are also designed to provide cross-platform interoperability and to minimize the cost of technology changes.

The future of inter-operable EHR systems will depend on choosing a common information/behavior model so that the benefits of these development technologies can be realized. The challenge is to make the use of a framework that implements that model something that all stakeholders find advantageous.

Personally Controlled Health Record

Tuesday, September 18th, 2007

Following my EMR-Facebook brainstorming post I ran across the IndivoHealth project (via WSJ-Health Blog). The announcement is that a consortium of large companies, Dossia, would be extending the Indivo open source core. Indivo has implemented the paradigm shift that I discussed.

The Indivo system is essentially an inversion of the current approach to medical records, in that the record resides with the patients and the patients grant permissions to institutions, clinicians, researchers, and other users of medical information. Indivo is a distributed, web-based, personally controlled electronic medical record system that is ubiquitously accessible to the nomadic user, built to public standards, and available under an open-source license.

Very cool. I guess I wasn't the first to think of this! 🙂