Wednesday, August 11, 2010

Net Neutrality in Healthcare

Net Neutrality is a topic that is heating up the interwebs.  Just Bing It (Google not being an impartial observer of trends here), or read this report from the Guardian.  Just a wee bit of thought and some recent experiences dealing with limited access due to my cell-phone carrier makes it pretty clear to me that I'm very much in favor of Net Neutrality.

The sheer audacity of Google to propose that: "Fourth, because of the confusion about the FCC’s authority following the Comcast court decision, our proposal spells out the FCC’s role and authority in the broadband space" has me flabbergasted.  I'd love to be in the position to tell a federal agency what to do or how to do it (and do quite a bit), and so would every other company in this country.   But I also expect regulators to take me with a grain of salt, and I expect them to take Google even less seriously than that.  Quite honestly, I feel much better about the FCC as a regulator than I do about the industry if Google and Verizon's response is any indication of what I'd get from the latter.

The "wireless/innovation" argument simply doesn't fly for me.  We've got more bandwidth and power today with cellphone/wireless than I had ten years ago with wired at home.  And, I know what can be done with that much bandwidth.  Wireless innovators have enough bandwidth to play with, without giving preferential treatment to anyone.

Favoring one content provider over another isn't the kind of "innovation" that I want.  Could you imagine not being able to effectively access your health records online because they are "second tier" content?  Would you like it if your wireless provider favored FOX or NPR for news content? 

I don't want my healthcare content impeded artificially in any way through the web.  I want my family, my healthcare providers, and my customers to have the same level of access to that content.


  1. You are dealing with a blind men and the elephant situation here. These are arguments about the hairs on the tail of the elephant. To put this in context, important things to understand are:
    - The MCI Decision
    - US vs ATT
    - Judge Harold Greene
    - Computer Inquiry I, II, and III
    - the April Decision of the DC District Court of Appeals

    A start can be the joint seminar of Harvard and Wharton on the FCC and Broadband Access. Videos (two sessions about 1.5 hours each) at and

    These still leave you with the elephant problem, but at least you've seen parts of the nose and ears also.

  2. This is certainly an issue that can impact and even inhibit innovation in healthcare. There could be some far reaching ramifications. Imagine having our transfer of digital imaging from diagnostic testing for an ED patient throttled so others still have the bandwidth for streaming hi def DVD. I think the FCC will need to take a very measured approach to any policy shift that takes a much more comprehensive look at the issue.

  3. It reminds me of when the Fed deregulating banking, with the help of Phil Gramm, TX. Help to cause Enron debacle. Wasn't that a TX company?

    Sure they can regulate themselves.

    I am not for more government regulation, but this effects everyone and almost every part of our lives.

  4. @Brian I'm not so sure I want Google or Verizon deciding what "Innovations" get bandwidth benefits. Your thought about the ED image being throttled for the benefit of hi-def DVD is exactly the reason why it the net should be content neutral. If you need bandwidth of X, you can plan for it and pay for it, and get it fairly, without having to worry about "how popular the content is".

    @fairhavenhorn I get the analogy, but my vision is to limited to know how it applies, educate me please. What are the other six parts I'm not seeing (in summary form please, I will watch the videos, but not everyone who reads this blog will).

  5. IP has had QOS since the beginning. 20 years ago in a different job, I was responsible for a TCP/IP stack for the DOS/Windows platform. I fully implemented QOS priortized routing. Many other stack vendors were doing the same at this time. So, this discussion at the technical level has been going on for 20 years.

    The problem with QOS is that it relies on the sender of a packet to correctly label the packets with the type of data. Once this is done the QOS works fine. Each router can have rules on how to handle the different types. It works out really well. We had plenty of connectathons showing that indeed we could have maxed bandwidth and yet the high priority traffic gets through, with minimal impact to low priority traffic.

    BUT, we found that no one wanted to label their data with any value other than HIGH PRIORITY. Even the e-mail people felt that e-mail was the most important traffic on the internet, proof was that e-mail was the largest volume of traffic.

    So, the whole thing falls apart because no one is willing to say their data is less important, and they will use the high priority value.

    This is the technical details... this has very little to do with the fight. There is no scarcity of bandwidth. But, publishers of data still want their data prioritized.

  6. Data servers can prioritize their data at their end of the conversation by PAYING FOR HIGHER BANDWIDTH. Thus it is the last-mile that is under discussion. This last-mile should be control of the CONSUMER. It is EASY for CONSUMERS to find bandwidth (well in most markets).

    If the proposal was to give me, as a CONSUMER, the ability to tweak the QOS priority at my end then I would like this.

    But it isn't... This is a effort by the CONTENT providers to tweak the QOS priority on my end.

  7. @John,
    I already pay for the "last-mile" bandwidth I want/can afford to both my cable and my wireless Internet provider today. Yes, I'd be rather upset if someone else gets to decide what that bandwidth is.

    On the "my data is high priority", of course that's what will happen. I think it would be better if you labeled the content (video, e-mail, et cetera), so that business rules could determine the priority.