I hope this helps everyone to keep track of what is going on.
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.
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.
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.
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:
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.
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.
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.
That pretty much sums it up.
[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 (osehra.org)
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.
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.
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.
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.
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.
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).
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.
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).
Congratulations to the OpenEMR team!!
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:
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.
Keith Boone, well known and liked Health IT standards geek has written up a proposal that would make the next release of HL7 CDA based on HTML5 rather than XHTML.
I have just become more deeply familiar with this set of standards as the result of the extensive research I have done on my new book on meaningful use of Health IT.
I can say, without a moment of hesitation, that this is a really good idea.
Everyone should support this proposal, b/c otherwise, CDA is a huge mess.
Which is not to say that an HTML5 version would not also be a huge mess. But I believe that it would be less of one.
The blue button initiative was a good initiative because it allowed greater access. It made that possible by ensuring that access to patient data did not have to wait for the VA/DOD/Whatever to create a download that conformed to the still-forming XML standards that make true interoperability possible.
But now the VA is promoting the Blue Button format as something that should be integrated into other EHR systems. That is unacceptable.
Meaningful use requries that doctors allow patients access to their health record summaries using CCR or CCD. Both of those standards can easily be translated to printable reports that are very readable. Meaningful use -also- requires that patients be provided a summary in a printed form. The simplest way to do this is just to have onsite printing of the CCR or CCD reports.
Blue Button data format is not as readable as a summary printout, and is not as parseable as XML. It is the worst compromise between human and computer readability. No clinician should ever make a clinical decision based on the content of a Blue Button download. The data is simply not rich enough to transfer into another health record or PHR. Essentially that makes the blue-button data format standard an FYI-only use case.
The innovation of Blue Button is to not let standards compliance get in the way of access. For this reason the DOD and the VA use of the Blue Button format should be applauded! The Blue Button initiative was fully give-me-my-damn-data compliant! But promoting it as an alternative process to a process that supports fundamental data reuse and is -already- required by meaningful use is unethical.
I formally request that the VA withdraw this contest, or make it clear that a CCR/CCD/printable report download meets the requirements of the contest.
Either you are promoting the notion of patient access, which is wonderful, or you are promoting shitty health data standards, which is unethical.
As far as I know, I was the first person to publish a generalizable method for creating a QR code stencil or to even clearly document why such a method was difficult.
However, since that time, I have realized that other approaches would ultimately be superior. The two I have been pursuing are automated embroidery of qr codes and improved stencils using laser cutting or 3d printing.
I will likely be abandoning the latter work, now that my early attempts have been eclipsed by Golan Levin at the Studio for Creative Inquiry at Carnegie Mellon. This work is being released from fffff.at, whose motto is: release early, often and with rap music.
Here is a link to his post on his new laser-cutter QR code stencil generation code. Along with his first application, a remake of hobo-coding.
Golan gave me a shout-out on the post he made. In some ways, it is hardly justified, since his method obviously surpasses my chicken-wire method in several ways. In fact, the only outstanding benefit to my method now is that it is much cheaper, and you do not need access to a laser cutter. The codes generated from his method are cleaner, and could probably be made smaller than my methods, and do not require an hour of working with caulk.
In a private email, he mentioned the possibility of a githib release soon…
In any case, take a look at the wonderful photos of the stencil in action.