[Welcome Slashdotters — feel free to leave comments here or there. But no debates on health care reform or what HR 3200 does or does not do, please — just on the concept itself.]
On the occasions where I have reviewed the actual text of major legislation, I have been struck by the parallels between legislation and software, particularly in terms of the pitfalls and issues with architecture, design, implementation, testing, and deployment. Some of the tradeoffs are even the same, such as trading off the risk of “analysis paralysis” (never moving beyond the research and analysis phase) and the risks of unintended consequences from rushing ill-formed software into production. Yet another similarity is that both software and legislation tend to leverage off of, interact with, call upon, extend, and/or replace existing software and legislation. Finally, the more complex a given system or piece of legislation is, the less likely that it will achieve the original intent.
But there are some critical differences that make legislation design both harder and higher-risk than systems design. (More after the jump.)
Software vs. Legislation
First, software is designed for a target or reference system; you can in theory predict or constrain its behavior, and its behavior is largely repeatable.
Legislation, by contrast, is executed by humans, with wide latitude for interpretation and implementation, as well as misunderstandings, disagreements on meaning, and on-the-fly modifications.
Second, software typically has several layers of independent (non-human) syntactic, semantic, and integration checking that it of necessity goes through before deployment (though plenty of defects can and do slip through).
Legislation, by contrast, is written in a natural (human) language, with all its gaps, faults, and ambiguities, and with nothing to force error checking in syntax, semantics, and integration; there’s no way of “compiling“, “linking” and doing a test run of the legislation in a limited environment before it becomes the (largely irrevocable) law of the land.
Third, because of the previous two factors, two or more software engineers can typically reach professional agreement on what a given section of source code will do; if they continue to disagree, there are standard tools and methods by which they can objectively demonstrate how the software will behave, either exactly or within general limits.
By contrast, and due to the corresponding factors with legislation, two or more people (legislators, executives, judges, and citizens) can interpret a given section of legislation quite differently, and each may well have a defensible position, due to the potentially wide latitude of and arena for interpretation.
Some Design Flaws of HR 3200
This all comes to mind as I have been reviewing HR 3200, aka the House bill on health care reform. While I am neither a legislator nor a lawyer (though I have worked closely with lawyers for a decade), I am a professional software architect/engineer, and a professional writer, who has worked in the IT field for 35 years. From that point of view, I believe HR 3200 will exhibit profound problems and unintended (or unclaimed) consequences if passed. Here are some of reasons why.
To begin with, HR 3200 suffers from all the problems listed above with legislation. It is written in English, and complex, obscure, jargon-laden English at that. Many of the sections are imprecise and/or incomplete, leaving large amounts of interpretation and implementation to unelected humans. Many of the objections to HR 3200 come from this very problem, including the concern that the ambiguity is deliberate and intended to open doors to politically unpalatable consequences.
HR 3200 is also massive and very complex — over 1000 pages in printed form, with hundreds of sections. For its sheer length alone, it is difficult to understand and interpret, but (as indicated below) there are other factors that make overall comprehension nearly impossible. It also makes after-the-fact revocation or even modification extremely difficult.
Much of HR 3200 makes piecemeal modifications to existing legislation, often with little explanation as to intent and consequences. So, for example:
SEC. 1148. DURABLE MEDICAL EQUIPMENT PROGRAM IMPROVEMENTS.
(c) Treatment of Current Accreditation Applications- Section 1834(a)(20)(F) of such Act (42 U.S.C. 1395m(a)(20)(F)) is amended–
(1) in clause (i)–
(A) by striking ‘clause (ii)’ and inserting ‘clauses (ii) and (iii)’;
(B) by striking ‘and’ at the end;
(2) by striking the period at the end of clause (ii)(II) and by inserting ‘; and’; and
(3) by adding at the end the following:
‘(iii) the requirement for accreditation described in clause (i) shall not apply for purposes of supplying diabetic testing supplies, canes, and crutches in the case of a pharmacy that is enrolled under section 1866(j) as a supplier of durable medical equipment, prosthetics, orthotics, and supplies.
Any supplier that has submitted an application for accreditation before August 1, 2009, shall be deemed as meeting applicable standards and accreditation requirement under this subparagraph until such time as the independent accreditation organization takes action on the supplier’s application.’
This happens repeatedly throughout HR 3200; in fact, one entire portion (Division A, Title IV) is labeled “AMENDMENTS TO INTERNAL REVENUE CODE OF 1986”. This makes it difficult — beyond the ambiguities of the language itself — to determine just what is being modified and what the potential implications are.
HR 3200 also suffers in places from what a software engineer would call “spaghetti coding“. In other words, a given section within HR 3200 (and there appear to be hundreds of them; numbers go from 100 up through 2531 and appear in numeric order, but there are many gaps along the way) will reference several other sections elsewhere in HR 3200, both above and below. Furthermore, it often requires careful reading going back pages to see whether a reference to a given section is to a section within HR 3200 itself or a section in existing legislation (such as the Internal Revenue Service code).
HR 3200 also comes across as similar to a “kitchen sink” application, that is, a single piece of legislation that attempts to do far too much. I will finish Part I with the table of contents for HR 3200 to give you a sense of all that it is attempting to do. Note that these divisions, titles, and subtitles could have been broken up into individual legislation.
Finally, HR 3200 embodies what is commonly known in software engineering as a “big bang” approach to systems development. In other words, HR 3200 attempts a massive and ill-understood (and/or ill-specified) modification to the nation’s health care system (roughly 1/6th of the economy) in one fell swoop. As such, it really represents the worst excesses of the waterfall development lifecycle, with deployment being hard or impossible to reverse.
Part III will suggest a different approach to health care legislation using good practices from systems development and software engineering.
H.R.3200 – America’s Affordable Health Choices Act of 2009 (table of contents)
DIVISION A–AFFORDABLE HEALTH CARE CHOICES
TITLE I–PROTECTIONS AND STANDARDS FOR QUALIFIED HEALTH BENEFITS PLANS
Subtitle A–General Standards
Subtitle B–Standards Guaranteeing Access to Affordable Coverage
Subtitle C–Standards Guaranteeing Access to Essential Benefits
Subtitle D–Additional Consumer Protections
Subtitle F–Relation to Other Requirements; Miscellaneous
Subtitle G–Early Investments
TITLE II–HEALTH INSURANCE EXCHANGE AND RELATED PROVISIONS
Subtitle A–Health Insurance Exchange
Subtitle B–Public Health Insurance Option
Subtitle C–Individual Affordability Credits
TITLE III–SHARED RESPONSIBILITY
Subtitle A–Individual Responsibility
Subtitle B–Employer Responsibility
TITLE IV–AMENDMENTS TO INTERNAL REVENUE CODE OF 1986
Subtitle A–Shared Responsibility
Subtitle B–Credit for Small Business Employee Health Coverage Expenses
Subtitle C–Disclosures To Carry Out Health Insurance Exchange Subsidies
Subtitle D–Other Revenue Provisions
DIVISION B–MEDICARE AND MEDICAID IMPROVEMENTS
TITLE I–IMPROVING HEALTH CARE VALUE
Subtitle A–Provisions Related to Medicare Part A
Subtitle B–Provisions Related to Part B
Subtitle C–Provisions Related to Medicare Parts A and B
Subtitle D–Medicare Advantage Reforms
Subtitle E–Improvements to Medicare Part D
Subtitle F–Medicare Rural Access Protections
TITLE II–MEDICARE BENEFICIARY IMPROVEMENTS
Subtitle A–Improving and Simplifying Financial Assistance for Low Income Medicare Beneficiaries
Subtitle B–Reducing Health Disparities
Subtitle C–Miscellaneous Improvements
TITLE III–PROMOTING PRIMARY CARE, MENTAL HEALTH SERVICES, AND COORDINATED CARE
Subtitle A–Comparative Effectiveness Research
Subtitle B–Nursing Home Transparency
Subtitle C–Quality Measurements
Subtitle D–Physician Payments Sunshine Provision
Subtitle E–Public Reporting on Health Care-Associated Infections
TITLE V–MEDICARE GRADUATE MEDICAL EDUCATION
TITLE VI–PROGRAM INTEGRITY
Subtitle A–Increased Funding To Fight Waste, Fraud, and Abuse
Subtitle B–Enhanced Penalties for Fraud and Abuse
Subtitle C–Enhanced Program and Provider Protections
Subtitle D–Access to Information Needed To Prevent Fraud, Waste, and Abuse
TITLE VII–MEDICAID AND CHIP
Subtitle A–Medicaid and Health Reform
Subtitle F–Waste, Fraud, and Abuse
Subtitle G–Puerto Rico and the Territories
TITLE VIII–REVENUE-RELATED PROVISIONS
TITLE IX–MISCELLANEOUS PROVISIONS
DIVISION C–PUBLIC HEALTH AND WORKFORCE DEVELOPMENT
TITLE I–COMMUNITY HEALTH CENTERS
Subtitle A–Primary Care Workforce
Subtitle B–Nursing Workforce
Subtitle C–Public Health Workforce
Subtitle D–Adapting Workforce to Evolving Health System Needs
TITLE III–PREVENTION AND WELLNESS
TITLE IV–QUALITY AND SURVEILLANCE
TITLE V–OTHER PROVISIONS
Subtitle A–Drug Discount for Rural and Other Hospitals
Subtitle B–School-Based Health Clinics
Subtitle C–National Medical Device Registry
Subtitle D–Grants for Comprehensive Programs To Provide Education to Nurses and Create a Pipeline to Nursing
Subtitle E–States Failing To Adhere to Certain Employment Obligations
About the Author: bfwebsterWebster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at email@example.com.
Sites That Link to this Post
- HR3200: A Software Perspective @ The Landsbloggers | September 7, 2009
- the Foresight Institute » ESP redux | September 8, 2009
- links for 2009-09-08 | Yostivanich | September 8, 2009
- HR 3200 from a systems design perspective (Part II) : Bruce F. Webster | September 8, 2009
- Well, Some Of The Slashdotters Get It « Tai-Chi Policy | September 10, 2009
- System Analysis and Legislation | Aaron Rogier | January 17, 2011
- Obamacare and the Thermocline of Truth : And Still I Persist… | September 28, 2013
- Obamacare and the Three Errors : And Still I Persist… | October 29, 2013
- Obamacare and Healthcare.gov: How We Got Here : And Still I Persist… | December 2, 2013
- Obamacare and Healthcare.gov: How We Got Here | | December 3, 2013