Subscribe via RSS Feed

HR 3200 from a systems design perspective (Part I)

September 7, 2009 12 Comments

[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.]

[Part II is now up.]

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 II discusses software architecture and development maxims, laws, and rules of thumb that appear to have application to creating legislation as well.

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 E–Governance

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

TITLE IV–QUALITY

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 B–Prevention

Subtitle C–Access

Subtitle D–Coverage

Subtitle E–Financing

Subtitle F–Waste, Fraud, and Abuse

Subtitle G–Puerto Rico and the Territories

Subtitle H–Miscellaneous

TITLE VIII–REVENUE-RELATED PROVISIONS

TITLE IX–MISCELLANEOUS PROVISIONS

DIVISION C–PUBLIC HEALTH AND WORKFORCE DEVELOPMENT

TITLE I–COMMUNITY HEALTH CENTERS

TITLE II–WORKFORCE

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:

Webster 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 bwebster@bfwa.com.

Comments (12)

Trackback URL | Comments RSS Feed

  1. Marty Nickel says:

    Analyzing legislation, especially this particular legislation, as software is a great concept. I’m afraid most the the slashdot crowd leans pretty heavily Democratic (I did notice the Sep 10 2009 link above). I think this is mostly follow-the-crowd or that’s-what-my-professor-said, rather than considered opinion.

Leave a Reply

You must be logged in to post a comment.