Running Motivation: shoe hacking failure

This is not intended to be a “running blog”, but it is intended to be a blog about how I am trying to hack my own running motivation.

I am a pretty big guy (almost 300 at times) and while I enjoy running, it is not because I am good at it. This is why I built my own running motivation software. I am not only the site designer (of course my family helps) but, I am also the demo account. So it is fairly easy to see how I am doing, from week to week.

Last time, I talked about how motivating it was for me to have cool shoes. Now, when I say running motivation, I only mean something that could motivate me to run more than one time. Watching an awesome video, for instance, might get me out the door once, but I need to have consistent motivation. Something that will get me out of the house every week, or at least contribute to getting me out of the house on a weekly basis.

So I was thinking of repairing my running shoes, and I decided to try sugru. The problem is that I should have let the sugru dry while it was on my foot. As it is, the sugru contracted and now I have these really uncomfortable plastic sticking into my toes.

I tried to repair my vibrams with sugru

Oh well. Better luck next time.

Now how has this impacted my motivation. Well Run Or Else is still working for me, I have made my distance each week since I have ruined my vibrams, but I am often walking rather than running.  Of course I am still nursing a calf injury, but mostly it is because I do not want to put on my old heavy running shoes.

So at least for me, having cool running shoes really does seem to impact my running motivation.


The e-patient reach

As many of my readers know, I am now regularly blogging on radar.

There, I have written a post called epatients: the hackers of the healthcare world.

It is pretty much a tour of how anyone who is already in the technorati, can become an e-patient. It heavily features the work that I have been doing with the Cautious Patient Foundation, which focuses very much on the information that every patient should know about how to prevent medical errors in the healthcare system.

But it also talks about the core of the e-patient ethos, getting access to data and leveraging it well. Being engaged and involved in your own healthcare. All of these are part of the Cautious Patient concept, and the e-patient concept. It has been very popular with the e-patient community.

Tomorrow, USA Today will be hosting the first version of the classic traveling medical blog summary Grand Rounds at

The fact that USA Today is hosting Grand Rounds is awesome. I have just discovered that my e-patient blog post will be one of the ones covered in the first edition of Grand Rounds hosted at USA Today. I am truly honored and wish I had spent more time removing commas from the article, which are, the, bane, of, my, writing, style.

Seriously, it is an important shift when mainstream media starts to pay better attention to medbloggers, the best of whom produce content that is tremendously valuable for our healthcare system. Even below average writers have something to add, but then… you already know that… because you are reading this!



Running Motivation: new shoes

Lately I have become interested in running motivation.  I am launching a running motivation app next week, and I thought I would give my readers a little taste of the process that brought me to design and build the new site.

Running is one of the best exercises. There are several that really compete for the throne of “best thing to do for your health” and IMHO it always comes down to a toss up between “control your diet” and “become a runner”. I love to eat. Never met a dessert I did not like. Never stumbled across a second helping that I was not a fan of. I have tried things to control my diet, but it just goes against my grain. In fact, I am going to make myself a PB&J right now…. O.K no bread… having frozen pizza leftovers instead. You get my meaning.

As I was saying. Diet control is just not what I feel like working on right now. I have worked on it in the past, I will work on it again, but for the last several months, running has been my obsession.

So I decided to think very carefully about how I could motivate myself to run. I started to examine, carefully, what stopped me from running each day. Eventually I realized that putting on my shoes was a pretty significant barrier. I am often wearing what would amount to “fitness clothes”, as a side effect of working from home. The only difference from my typical “work from home” outfit and my “I am running now” outfit was my shoes. Working = sandals, Running = running shoes.

So I decided to try Vibram Five Fingers, which is very popular with the Quantified Self community. The basis idea of the shoes is that they change your stride from heel-toe to toe-heel. And they did change how I run. But that was not actually the reason I got them. I got them so that I could feel really awesome and cool when putting on my running shoes. I was trying to daily hangup that was keeping me from running.

Interestingly the Vibram Five fingers have also helped with another project of mine, to become more mindful. I realized that normal shoes were isolating me from any experience of the ground. Normal shoes ensure that I experience grass, or mud, or dirt or concrete or asphalt in all the same way. All I “feel” is the bottom of my shoe, which is always the same, which means that I can effectively disconnect mentally from my environment, at least as far as experiencing the ground goes.

Using the Vibram Five Fingers, I feel just about everything, but I am somewhat protected from the damage that random pebbles and twigs might otherwise do to my feet.

Mindfulness is all about being in your own body rather than in your own head. Experiencing what is around you and being in the moment, rather than giving in to your internal thought monologue. It is extraordinarily difficult for me to be mindful, even a little, but the shoes actually help. They remind me that I am stepping on something, and that this is connected to where I am right now. Generally that pulls me in a mindful direction. I have started going without shoes all together to enhance this effect. It helps.

I wish that I could end this article with a resounding endorsement of Vibram’s product, and if I had “standard issue” feet, that is exactly what I would do. Unfortunately I do not have standard size feet. I have really long and narrow feet. Vibram’s design presumes that my toes should be much wider than they really are and as a result of this my big toe pulls outside of the protection of the rubber sole. This is much easier to show then describe:

You can see how my toe actually pulls to the right of the rubber that is intended to protect the toe.

Eventually, this happens..

As you can see, I have been running on the cloth rather than the rubber because my too thin toes pull out of the rubber protection. I said “rubber protection”… (ha).

So the Vibrams are awesome… unless you have thin feet. I am looking for a “barefoot running” shoe that does not have toe slots as a replacement. Still I like my Vibrams and I am glad I got them.

The real upside is that this running motivation hack, get shoes you think are cool, actually did work for me. My running went up substantially as a result! For most people, these shoes will work just fine!


The Patient Scientist

Over on the Society for Participatory Medicine mailing list we have been discussing the recent Readers Digest blog post titled: 50 things your nurse wont tell you.

You really have to read it before reading this article, this post will only make so much sense without that.

I suggested that part of being an epatient or a perhaps a cautious patient was being able to filter an article like this one as a “patient scientist”. E-patient Dave, as per normal, was not about to let me get away with just that, and asked “So, Fred, does that point (how to filter an article like this) become a P.M. teachable?  And thus bloggable?”

So I figured I should take a moment and eat my own dog-food.

The first thing to note is that the role of the patient scientist is not an authoritative role. But the role of -any- scientist is not an authoritative role. Rather, it is the job of a scientist to be “carefully and productively dubious”. I believe that an engaged patient has an almost greater capacity to pursue this ideal than a doctor. One of a doctors roles is as a scientist, but only one of several roles. Another role for a doctor is to act as an authority, to posit a hypothesis rather than merely questioning. To put forward one particular idea and defend it with expertise and authority. But the patient has the privilege of merely questioning, without ever taking a stand on the idea in question. Ironically, this means that a patient can play the role of a scientist more completely than a doctor.

That might read like something as a contradiction but it isn’t as long as we clearly define science as “the process of productive questioning” and scientist as “the one who productively questions”. In the doctor patient relationship, the patient should be the “theory questioner” and the doctor the “theory maker”, which, in that brief moment, means that the patient is the one in the scientific role.

The irony ends here, of course, because while the doctor is in the “hypothesis making” role, the patient too often fails to properly take the “questioner” role. Further, the doctor is a trained scientist, so in reality the doctor is both putting forward a hypothesis, and also questioning it. Doctors who expose this internal dialogue are rarely paternalistic, because they expect the patient to understand that a diagnosis or a treatment plan are testable hypotheses. That can be pretty difficult for a patient to handle, but facing that uncertainty head-on is the central task of the e-patient. Extending this idea further, we can see that getting a second opinion is really just a special case of the scientific peer review process.

Being a patient scientist is a central part of being an engaged patient.

So how would a patient scientist read the list of 50 things your nurse wont tell you? Lets take a look. I will paraphrase the 50 points into statements that I can evaluate.

  1. if I say, ‘You have the right to a second opinion,’ that can be code for ‘I don’t like your doctor’
  2. sometimes the doctor won’t order enough pain medication.
  3. the stuff you tell us will probably get repeated (gossip)
  4. Gentler butt-wiping for nicer people.
  5. The nurse might not let you know she is worried.
  6. The nurse might not let you know that you are doing medically stupid things.
  7. If you’re happily texting and laughing I’m not going to believe that your pain is a ten out of ten
  8. The nurse assumes you are underestimating your use of drugs and alcohol.
  9. Nurses head off medical errors
  10. you can’t get admitted unless you’re really sick, and you’ll probably get sent home before you’re really ready
  11. nurses are overwhelmed by red-tape and charting
  12. hospitals are still filthy and full of drug-resistant germs.
  13. went to nursing school because I wanted to be a nurse, not because I wanted to be a doctor and didn’t make it.
  14. Grey’s Anatomy is not reality
  15. I’ll have a dying patient with horrible chest pain who says nothing, because he doesn’t want to bother me. But the guy with the infected toe…
  16. If you abuse the call button, you will get a reputation that can diminish the quality of your care later.
  17. You need to include herbals and other over the counter medications when you are asked about medications.
  18. This is a hospital and not a hotel
  19. This is a hospital and not a hotel
  20. The nurse might have test results but are waiting on a doctor
  21. When you ask me, ‘Have you ever done this before?’ I’ll always say yes. Even if I haven’t
  22. Nurses do not always help nurses
  23. Correcting difficult doctors is difficult creating opportunities for mistakes
  24. Doctors can be willing to blame nurses in a way that steals trust.
  25. If you would be willing to make a formal complaint when things go wrong, consider making a formal compliment when things go right.
  26. Nurses like to see long time patients return once they are healthy
  27. sometimes Nurses can make miracles happen
  28. Make sure you are not ignored when you say important information, even if the provider is looking at your chart.
  29. Never talk to a nurse while she’s getting your medications ready.
  30. Understand the chain of command for complaints and nursing is a demanding job
  31. If the person drawing your blood misses your vein the first time, ask for someone else.
  32. Never let your pain get out of control. Using a scale of zero to ten, with ten being the worst pain you can imagine, start asking for medication when your pain gets to a four. If you let it get really bad, it’s more difficult to get it under control. (one of the few that I did not summarize)
  33. Ask the nurse to wet your bandage or dressing before removal
  34. If you’re going to get blood drawn, drink two or three glasses of water beforehand. If you’re dehydrated, it’s a lot harder for us to find a vein, which means more poking with the needle
  35. Don’t hold your breath when you know we’re about to do something painful, like remove a tube or take the staples out of an incision. Doing that will just make it worse. Take a few deep breaths instead.
  36. don’t go into the hospital in July when the new residents start.
  37. Doctors don’t always tell you everything about your prognosis
  38. Have you washed your hands?
  39. Many doctors seem to have a lack of concern about pain. I’ve seen physicians perform very painful treatments without giving sedatives or pain medicine in advance, so the patient wakes up in agony.
  40. When you’re with someone who is dying, try to get in bed and snuggle with them. Often they feel very alone and just want to be touched. Many times my patients will tell me, ‘I’m living with cancer but dying from lack of affection’.
  41. warm the towels
  42. Sometimes desperate end-of-life measures are more torture than comfort.
  43. Husbands, listen to your wives if they tell you to go to the hospital.
  44. doctors diagnose but nurses heal
  45. If you do not understand what the doctor is telling you, say so
  46. know the next steps for your care.
  47. doctors help you understand whats wrong with you, nurses help you understand that you are still normal.
  48. don’t ask me out on a date.
  49. have a positive attitude
  50. say thank you.

First concept: Patients need Social Skills to get better care?

Ok, so first of all there are alot of things here fall into the category of “its better to be nice to your nurses” and/or “have the right attitude”. Specifically #4 , #15, #16, #18, #19, #25, #41, #48, #49, and #50 are all in this class. All of these are social skill issues. Of course, the recommended approach here is “You catch more flies with honey”, but that is probably not the right synthesis here. In fact that saying is a perfect example of a statement that does not bear scientific scrutiny.

In fact, real social skills does not mean “always be nice”. Social skills include how to complain effectively, how to confront without offending, and how to be gentle while still being insistent. Number 15 is a good example of this. The guy with the chest pain is not complaining enough, the guy with the toe pain is complaining too much. Social skills, at least for a patient, means knowing when being nice is not working, and something else is called for.

So now we have a statement that we can evaluate against evidence: “Do patients with better social skills get better care?”. Everyone who I talk to in medicine indicates that highly functional social skills are absolutely a predictor of good care. A quick review of PubMed shows that it will be difficult to search for something like this. Because searches on “social skills” usually return information about mental health. (i.e. social skills of psychiatric patients) but at least we have distilled a large portion of these points into something that A. we can evaluate scientifically (i.e. search for and consider published evidence) and B. we can engage with. We can discover if better patient social skills leads to better outcomes for patients and, if so, we can evaluate methods for improving our own social skills that might improve the quality of our care.

Part of a scientific consideration of a statement is to evaluate openly the biases of those who are creating statements. One bias is obvious here. This is the largest “grouping” that I could find in the “secrets from nurses” and it clearly shows a “appreciate us” bent. Perhaps, the frequency of this class of suggestion in the list is due to nurses feeling under-appreciated (a common problem) rather than its usefulness to patients. An “agenda” is a common bias in self-reported data. As patient scientists it is important to ferret out sources of bias in data we receive, especially from main stream media. All patient scientists should become comfortable with Wikipedia’s Bias category.

Pain management.

There were several comments regarding the mishandling of pain medication.

#2 suggested that doctors do not always order enough pain medication. #7 indicated that the nurse is going to be judging the validity of your pain reporting, and might find you unbelievable.  #32 gives specific advice regarding controlling pain, specifically, that pain should be controlled before it really gets bad. #39 indicates that Doctors can be cavalier about pain.

All in all that is four entries on issues surrounding pain control, but with very divergent perspectives on the problem. It should be noted that at least two comments focus on the fact that doctors sometimes fail to effectively control pain. So is pain management a problem in hospitals? The evidence is easier to find here: The Joint Commission, an non-profit hospital accreditation organization, has made pain management part of its accreditation  and education process. The joint commission is an evidence-based organization, which means that if it is focused on pain management, it is because it -is- a problem. I could dig deeper, into the research that the Joint Commission is using to drive its policies… but this is enough for now.

What is the take away lesson for e-patients?

If you are in so much pain that you cannot fall asleep, then your pain is not controlled. This rule applies even if you do not feel like you need to sleep right now. Its not about being tired, it is about anchoring your pain score around something objective. If I say “my pain is a 5” and you say “my pain is a 7” it is difficult to accurately compare those, or to determine from the number if the pain is under control. Whether or not you could fail asleep is a much much better measure. Too painful to sleep = too painful.

But understanding what pain levels are not tolerable is not enough. A patient must understand how to go about getting pain relief form the system. As the nurses suggest, sometimes the doctors simply do not care. Sometimes the ball gets dropped for other reasons, orders get shuffled, or medication orders do not go through. You might be suffering pain because someone has lost their sense of empathy, but it could be just as easily because a workflow is broken. As an e-patient, it should not matter why the pain is not being treated, you simply need to understand what you need to do to change the situation. Dr. Oliver has written lots about this, but the take-aways that I remember are.

  • Someone needs to be keeping a journal of events in the hospital.
  • This person should probably not be the patient. If you are in the hospital, you are probably so sick that you cannot discharge this responsibility yourself.
  • Which is one of several reasons that patients should not be left in the hospital alone.
  • The journal should include records of when pain medication is requested, as well as the time, medication name and dose when pain medication is delivered.

Pain control is something that Dr. Oliver writes about, which is where I am getting this short-hand advice. Dr. Oliver is my boss at the Cautious Patient Foundation and we regard failures in pain management as medical errors. As a result this is an area that I am concerned with as a technologist, and this is a core area that we educate about.


So I hope I have demonstrated, a little, how I think a patient scientist should react to anecdotes like the ones collected by Readers Digest. Treating them as “true” is a mistake, there are complex issues underneath, but it is possible to use them to start a critical thinking process that can lead to positive results.

I would also be interested in answering the following questions from the texts:

  • “Is there evidence that patient reputations (i.e. between nursing shifts) can lead to poor care?”
  • “What end of life issues are not typically being discussed by nurses? what damage can this cause to me as a patient?”
  • “How tolerant should I be as an e-patient with poor blood drawing skills? Can proper hydration be used to address this problem?”
  • “Are there higher medical error rates in July?”

All of these can be posed as a hypothesis, and approached scientifically by a patient.

I think it would be interesting to see some of these questions approached by other patient scientists. If you decide to blog about one of these, do send me a link.


OCR refuses FOIA request

Joe Conn, one of the best Health IT reporters I know, has been denied FOIA access to breach data reported to the Office of Civil Rights.

Honoring FOIA requests is a critical part of how the people ensure that the government is not abusing its power. That might sound paranoid, but blanket rejections like this are deeply problematic and are often evidence of deeper issues.

Given that this is directly related to the documentation of abuses of patient privacy, I should expect that Dr. Peel will want to get involved. Frankly, it is moments like this that I am thankful that someone like Dr. Peel is as tireless and relentless as she typically is.

When a FOIA request is refused in this manner, it will usually take a judges involvement to open things back up.


Steve Jobs is dead. Long live Steve Jobs.

Today, Steve Jobs died.

This blog post will be only one among thousands of posts devoted to his drive and his genius. Thousands will celebrate a technical legacy that almost no technologist can hope to replicate. The original Macintosh, those early films from Pixar, the iphone… hell I am typing this on a Macbook Pro (dual booting Fedora… but still…).

I think this might as well be a good time to mention why it is that I do what I do. I lost my mother to ovarian cancer almost 10 years ago exactly.

I work on Health IT rather than more lucrative endeavors for one simple reason.

I will never cure cancer.

I am not even sure that “cancer” is curable. Cancer is too deeply related to the way our cells normally function in order to simply be “cured”. There is a good chance that all we will ever get is “really good treatments” for cancer. But it hardly matters for me. I will not be the guy who finds the cure or the “really good treatment”. I am a computer scientist, its just not what I do.

But my mother did not just die from cancer. She also died because of a medical error. A doctor had enough information to diagnose my mother correctly many months before we discovered that she had ovarian cancer. But doctor missed the signs. That is pretty common with ovarian cancer, it is less common than breast cancer, but more often fatal because it is harder to detect. Still, the signs where there. The doctor thought it was the flu.

Once cancer has gone too far, fighting is an uphill battle that many, including Steve Jobs, lose in the end. My mother died at 52. Jobs died at 56.

Is cancer an uphill battle or a downhill battle? Early detection is everything. And early detection is an information problem. It is a diagnosis problem.

It is a computer science problem.

Reading about Steve hits me pretty hard. He was one of us, a geek. Not just a geek, but a visionary among geeks. I do not square with the Jobs ideology… but I have to admit, he did some amazing things.

Steve Jobs said that he wanted to put a “ding in the universe”. And he did.

But the ding that I want to make in the universe is so much greater. The ding that I want to make is to make it much much rarer for us to lose people like this. Can you imagine what Steve Jobs could have accomplished if he had lived another 10 years? 20?

I will never be as famous as Steve Jobs and I will never be able to make as much of a difference as he did. If any progress at all is made in health IT it will be due to the cooperative work of tens of thousands of geeks with my skill set. But I am pretty hopeful that the area I am working in can really make a difference in the world. I hope that we might be able to make a few more critical diagnosis in that critical window where we might actually save some lives.

Tonight I will toast Steve Jobs, and to my mother. This is a good a time as any to reveal my addition to the latest painting by Regina Holliday. I did not tell her this, but I watched her paint this on the 10 year anniversary of my mothers death. I did not get to be with my family at the graveside that day, but Regina decided that others could add to her painting… so I added this.

dear mom, if i can change the code, I can change the world.

That pretty much sums it up.


VistA Custodial Agent Launches, and it doesn’t suck (much)

[Update 2011-10-19 Many of the issues here applied only to the initial launch of OSEHRA and began to be addressed almost immediately. Do not assume everything you read below still applies]

As typical, I was alerted to the fact that Tiag, the winner of the Open Source VistA custodial agent competition, has launched a website and new non-profit foundation called Open Source Electronic Health Record Agent (

The good news? The site, and the foundation both seem to be moving in the right directions. The site appears to be using a Drupal backend, which is a reasonable choice. The foundation has made pretty strong technology and licensing initial positions and those initial positions are not stupid. They have done -some- stupid things, but for the most part these appear to mostly be relatively minor errors that hopefully can be fixed.

Strongly pushing the Apache License

Something that OSEHRA is doing right is to strongly push the Apache 2.0 license, without insisting on it. The whole licensing document makes a compelling case for Apache, and for the right reasons. Apache has a reputation as strong non-copyleft Open Source license because it is GPLv3 compatible, it is more explicit, and handles patent issues well. It is a strong license and almost every informed person I know in the Health IT community prefers it when non-copyleft is required (which it obviously is in this case). But they consider their licensing document in draft, which I assume they leave some room for debate on the subject.

Strongly pushing git

Another smart thing they have done is to setup a git repository. VistA, in order to survive, must have a strongly distributed version control system. Git is by far the best option for this, given how much it has pulled ahead of the other Open Source distributed version control systems. Git has some fundemental advantages for projects that are as large and expansive as the Linux Kernel, and VistA is just such a project. OSEHRA has nothing in their VistA git repository so far, but they fact that they already have a repository is a very strong move.

I seriously doubt that many of the TIAG contractors actually understand how difficult running any kind of software version control system is for VistA. To actually pull it off, it is likely that someone is either going to have to build some KIDS-to-git software bridges and/or develop some very methodical development processes that allow an individual instance of VistA, in a KIDS environment, to function. It is hard to know if TIAG is being smart here or just really lucky. We may never know unless Joseph Conn’s FOIA requests efforts reveal more from their initial proposal. (BTW, given that the VA is stonewalling it would be smart for TIAG just to hand over their proposal to Conn, for the sake of transparency).

OSEHRA is putting all of its chips on long term VistA-git compability. Specifically, their testing and certification strategy centers on using Gerrit, (a git-based source-code review tool) to ensure that new contributions to VistA are safe and compliant. It is unclear to me how this system squares off against the KIDS-based Class I, Class II and Class III software evaluation and deployment system that the VA currently employs.

Perhaps Tiag is lucky to choose git, perhaps they are smart to chose git. Either way, I’ll take it. Git is one of very few systems that has the brawn to potentially solve the most vexing KIDS-vs-VCS problems. It is a smart choice. Pretty much the only choice that might have been stronger would have been to endorse Medsphere’s preexisting work on bazaar. Since the decision by Medsphere to back bazaar, git and mercurial have surged ahead as more popular distributed version control systems. Specifically the git community, centered around github, has become the standard for enabling Open Source development. Take a read on the short whitepaper covering the OSEHRA repository strategy. It is obvious that Tiag gets the potential of Git, but it is difficult to see if they fully understand the complexities in existing in the nexus of git+KIDS+GTM+Intersystems as technology stacks. Still, who gives a damn if they understand what they are getting themselves into if they are still taking the right strategy? There really is no other rational way forward in this technology issue. I am pretty happy about this.

Long-term the foundation board is community elected

According to my initial skim of the current OSEHRA by-laws, the DOD and the VA, along with Tiag, initially appointed three board members. However, when the term of these board members expire, they will be re-elected by the membership. I would love it if someone with either some legal expertise and/or more free time can read the by-laws carefully and see if my understanding on this is correct.

If it is, then there is a basic mechanism in place for OSEHRA to actually represent the community, something that has been missing in WorldVistA for years. This is pretty good news.

NDA in the Membership Agreement

The largest of these is the Membership agreement. At this time, no Open Source developer or company should consider joining the OSEHRA organization, or even register for the website. The current OSEHRA membership agreement contains a tremendously broad non-disclousure agreement. Here it is:

Confidentiality.  Member acknowledges and agrees that all information disclosed by such Member or received by such Member relating to the Corporation, including information discussed in any meetings of the Corporation, shall be presumed to be confidential (the “Confidential Information”) unless otherwise stated by the disclosing party.  Member hereby agrees to keep the Confidential Information confidential and not disclose the Confidential Information to any party other than its Representatives, whom it will cause to observe the terms of this Agreement, using the same degree of care that it exercises with respect to its own information of like importance but in no event less than reasonable care.  Confidential Information does not include information which:  (a) is rightfully obtained by a recipient Member without breach of any obligation to maintain its confidentiality; (b) is or becomes known to the public through no act or omission of the recipient Member; (c) the recipient Member develops independently without using Confidential Information of the Corporation or any other Member; (d) is disclosed in response to a valid court or governmental order, if the recipient Member has given the disclosing party prior written notice and provides reasonable assistance so as to afford it the opportunity to object; (e) information that is known to the receiving Member prior to disclosure by the disclosing party; (f) information that is approved for release in advance by written authorization of the disclosing party; or (g) information that is rightfully disclosed to the receiving Member by a third party not bound by a confidentiality restriction.  Member understands that the Corporation does not contemplate the exchange of competitively sensitive information.

No Open Source software developer I know would be willing to agree to this. It basically allows other ‘Members’ of the corporation to limit what can be coded by simply communicating ideas through OSEHRA. The agreement presumes that information from the OSEHRA is confidential -by default- which is so deeply contrary to the values of Open Source it is not funny. As an Open Source developer, whenever someone starts to tellme “This is confidential information…” I stop them immediately and tell them not to tell me any more. The only reason that I do not consider this a big deal is that it is obvious that OSEHRA simply did not think this through and allowed boiler-plate legalize to slip into its document process. They will fix this because, I, and countless other Open Source developers will not be able to participate under these terms. I know this because the other important document that they have created is their draft Software Licensing document. In that document they get the basic idea of openness right.

Non-disclouser agreements, like the one in the paragraph above, serve to create fodder for “trade secret” litigation.  Trade secrets are a mirky aspect of “intellectual property” law (I use the term ironically), because in order to have an action under trade secrets law, you need to basically show that you were keeping a secret, and someone else did something wrong in obtaining and taking advantage of that secret. (IANAL, but this is not just my understanding). Non-disclosure agreements are a big part of the process for ‘protecting’ trade secrets. Trade secrets have little use in the Open Source community, and elsewhere OSEHRA recognizes this. From its consideration of “intellectual property” law in the draft software licensing agreement:

The final bullet point, trade secrets, is mostly irrelevant and not applicable in the context of open source projects given that openness and transparency are some of the required characteristics of open source and are enforced by the best practices. We exclude trade secrets for the subsequent discussion in this document.

Obviously, the fact that the membership agreement at OSEHRA fundamentally endorses and protects trade secrets, which they know is not a part of the Open Source ethos must simply be an example of the left hand not knowing what the right hand is doing.

Still, no Open Source developer or company should consider joining OSEHRA while the click-through membership agreement contains these terms.

Commercial vs Proprietary

A pet peeve of those of us who make a living writing and supporting Open Source software is when people say “Commercial” when they mean “Proprietary”. The word “commercial” simple implies that someone is being paid for working on software and implies a certain amount of professionalism. There are plenty of commercial Open Source companies out there. Red Hat is a great example of a general commercial Open Source company, and Medsphere certainly considers itself a commercial Open Source Health IT company.

Sometimes, OSEHRA uses “commercial” correctly, referring to both proprietary and Open Source individuals and companies:

In the context of open source software development, it is very important to prevent patented methods from being implemented into the code, given that they restrict the use of the software and undermine the emergence of a commercial marketplace in the ecosystem. Patents undermine the environment of trust that is required for a collaborative ecosystem to be successful. Commercial companies will be unlikely to invest and build upon the common resources of the ecosystem if there is a suspicion that this will result later in costly patent litigation.

underlines are mine. This use of “commercial” is appropriate. But the following one is not.

The OSEHRA should not adopt GPL, a restrictive “free (libre) software” license that limits commercial interests.

This is a false statement. Red Hat lives and dies by the GPL in the Linux kernel. It is a commercial enterprise. What the GPL limits is “Proprietary business models”. It means that commercial companies have to share improvements. The GPL aligns corporate “interests” with community interests. It is not the “commercialness” of companies that is limited by the GPL, it is their “proprietary-ness”. This problem becomes more apparent with:

The OSEHRA will continuously encourage members of the ecosystem, both commercial and non-commercial, to contribute back to the code base any improvements and modifications that they made to the code.

There will be almost no “non-commercial” members of the eco-system. There will, however, be a continuing debate between proprietary vendors, hybrid proprietary/Open Source vendors, and fully Open Source vendors. Labeling this as a distinction between “those who which to make money and those who do not” is to be intellectually dishonest about the core debate.

Any frequent reader will know that I favor Open Source processes and copyleft licenses. But the argument against my positions is legitimate: proprietary software licenses can help ensure that developers are paid fairly for their work and contribute to long term sustainability of software development. I get that. I wish there was a way to ensure that developers could more safely invest in Open Source code development, and I have been financially taken advantage of by free-loaders in the Open Source community more than once. I have the intellectual honesty to admit that there is a real-debate here, with valid points on both sides. But the divide is Open Source vs. Proprietary and not Open Source vs. Commercial, or Non-Commercial vs. Commercial.

This is insulting terminology, that artificially endorses the positions taken by proprietary vendors and glosses over the consequences of their positions. (i.e. the word proprietary gives some hint about the tremendous amount of control that a proprietary vendor holds over a user, whereas ‘commercial’ gives no such hints).

Ambiguous Ethics Terms

I have a degree in Philosophy and a minor obsession with ethics. I call people out in the Health IT frequently and, some might say, harshly.

I am convinced that discrediting those who deserve to be discredited is an important part of what it means to be ethical in Health IT.

But the OSEHRA Code of Conduct says:

Working to instill public and consumer confidence relating to electronic medical records, its member companies, and its professionals, avoiding any action conducive to discrediting members of OSEHRA, Inc.

Being a member of OSEHRA will never exempt some from a need to be “discredited”. Hell I am not sure I could even define what “discredited” means here, but I am pretty sure if I feel that someone who happens to join OSEHRA deserves to be discredited, that OSEHRA should not have anything to say about that. For instance, would this famous post from ONC regarding the use of the term EHR over the term EMR serve to “discredit” EMR technology? This is the only place that I can find on the OSEHRA website where the term ‘electronic medical record’ is preferred over ‘electronic health record’. Would ONC qualify for OSEHRA membership?

I am also unsure of how scheduling an untimely party could be unethical:

Refraining from scheduling general attendance meetings, receptions or other events at times that conflict with substantive programming or social events at OSEHRA, Inc. meetings without the express prior written permission of OSEHRA, Inc.

This raises the strange possibility that I might use my deeply nuanced understanding of the basic motivation constructs of Open Source software developers (they like free beer) to create an alternative social event (free beer party) that would compete with “substantive programming” (a boring meeting) that would put me in violation of the “ethics” of OSEHRA. Seriously?

Again, I think this is an example of boiler plate language slipping through without careful examination.

Every Open Source project has unwritten policies regarding basic courtesy among software developers. Generally, it is frowned upon to criticize individuals directly, but ideas can and are frequently judges very harshly. When a person strongly associates with a bad idea they can expect some unkind words. But these unkind words always focus on the quality of the ideas.

Any Open Source community code of conduct is either a paper tiger or has some acknowledgement that heated technology discussions are the norm in the Open Source world.

No automated document forge

Putting aside the complexities of git+KIDS, software development is not the most important set of tasks facing OSEHRA.

OSEHRA is intended to be the middle man on a lot of really thorny policy and governance issues. The documents that they have created, including their white-papers, and corporate documents are far more important than any software issues they might attempt to address at this stage. But OSEHRA is not yet using an effective document forging process.

There is an art to Open Source document forging, and everyone is familiar with the wiki concept. But wikis are not  ideal for gathering commentary on formal documents. Community commenting was advanced most substantially by stet, which was used to enable thousands of comments on specific sections of the GPLv3. Stet is a dead project but the heir apparent is a project and service called c0-ment. Co-ment enables a community to build consensus around the contents of a document in the same way that a bug reporting engine allows the Open Source community to improve code. All of the documents that OSEHRA is developing, and even those that it considers “done” should be submitted to a community comment process enabled by co-ment or software like it.

Apparently, lots of people read this blog. I have the server logs to prove it. I even had Roger Baker comment on my last blog post on Tiag. I remain surprised by things like that, since I write primarily about things that amuse me in ways that amuses me. I always assume that my readership is limited to other geeky ideological information revolutionaries like myself. But apparently, important decision makers and thought leaders are reading this (Hi Allison).

Which is a problem, it means that my voice, as an abnormally high-profile hacker/blogger is automatically weighed higher than others in my community. In fact, my proclivity to spend hours typing up an analysis like this makes me a worse technologist, not a better one. It is critically important that OSEHRA develop processes that embrace the insights of my community who constantly prefer hacking over writing. They need to hear from the guy who is going to read this article and then spend the next 4 hours hacking to see if he can write a working KIDS-to-git translation script. Systems like co-ment dramatically lower the barrier for developers like that to participate in a document creation process. They do not have much time to contribute to commenting on governance issues, but if the OSEHRA governance process does not work for these hard-core developers, then it will cripple OSEHRA in the long term.


I am very pleased with the first pass that OSEHRA and Tiag have taken here. They are making some smart moves and most of the mistakes that I point out here are minor infractions that can either be quickly fixed (the NDA problem) or do not matter that much (the code of ethics issues).


Practical collaborative document writing for patient communities


I have a lot of experience with collaborative document writing, and now, in my role with Cautious Patient Foundation, I have been providing technical help to several patient communities. I helped write the security standards for the NWHIN Direct project and I am currently working with the e-patient/QS community to create a document detailing Doctor friendly Quants and Quant friendly Doctors.

My advice is pretty simple:

  • Use a forum, either a facebook thread or a mailing list to determine who the primary authors should be, and what the general content of the document should be.
  • If you have several authors, use Google Docs or a Wiki for initial document creation. If you are writing alone, use whatever you want as your initial author tool.
  • Once you and your co-authors feel OK about the resulting document, copy it over to, and allow your entire community to comment on it. (For Geeks: Co-ment is the successor to the stet project which was used to coordinate comments on the GPLv3.) There is a free version of co-ment but the service is cheap and probably worth it. It allows a community to comment on specific parts of a document, and it will automatically generate a “heat-map” of the more controversial parts of the document.  These are the areas that you will need to spend time with, ensuring that you have blessing of your community.
  • When the comments stop coming in, the document is done.
  • Keep your document as short and concise as possible. All of us operating in the various patient communities are short on time, and by keeping what you are asking us to read short, you are respecting that.

The insight here is that while a wiki makes it easy to update and maintain documents, they are not always the right tool for building consensus in a community. What you want is to have your documents reflect the will of your community at large, rather than the will of the most obsessive wiki-editor in your community.

Hope this helps.