Replies

From a webdev standpoint, The HealthCare.gov website's functions should be as follows:

Accept input data via forms
Write input data to a database
Read input data to display on screen, reporting or document creation
calculate insurance costs based in data input

Conceptually, yes; implementation wise, no… precisely because data needs to be validated between #1 and #2.
Here's why: Healthcare data.

Consider something as simple as a social security number; off the top of my head:

JavaScript dependence/disabling: nothing in this site should require javascript, as its use is [essentially] mandated by the government and therefore must comply with ADA and accessibility standards, including text-only browsers.
Because of #1 you cannot count on client-side validation, therefore *all* validation needs to be done in the client-side code.
Because of #2, a SSN may come in in several forms: dashes, no-dashes, spaces, etc. (You can do this w/ regex, though regex solutions are typically too brittle for complex [i.e. non-regular] data.)
Because of #3, combined with the general inability to declare types, it is now incumbent on the programmer to do [at least some] flow analysis when making any changes. (i.e. ensure all inputs to the function are validated.)
(Mitigated if using OOP; however, OOP is rather bolted-on in PHP, there are many tasks for which OOP is an unnatural solution, and there can be memory concerns on some systems [admittedly may or may not be an issue in newer PHP versions].)
Now we need to add it to the DB&hallip; wait, did you know that a SSN isn't unique? (Did you set up the DB assuming they were? Is your code assuming they are?)

Validation though is the 'core', if you will, of verifiable S/W — which you want for critical medical systems. (I'd argue for even non-critical medical systems.) The above is actually very small, and as such there are things you don't even need to really account for, like poor Bobby Tables, because the data is just a numeric-string — once you get into validation PHP quickly becomes terrible, because of the loose take on types.

The above validation-insurance for SSN can be expressed in Ada as this:

Type User_ID is new Positive; -- ID for a record; cannot be confused w/ a integer-count. Subtype Digit is Character range '0'..'9'; -- The following is a string, of length 9, that has ONLY digits. Subtype Social_Security_Number is String(1..9) with Dynamic_Predicate => (for all C of Social_Security_Number => C in Digit); -- The following function cannot have an invalid invalid SSN parameter. Function Save( SSN : Social_Security_Number ) return User_ID;

I can make the above guarantees because they are ensured by the language; without ever looking at the body of Save I can tell you it cannot be called w/ an invalid SSN and that it will return a positive integer. Moreover, the guarantees can be used to prove the program's correctness w/o relying on any flow analysis. (Flow analysis might be needed on the internals of functions, but not on the interfaces; thereby allowing for far better modularization and subsystems.)

Sorry folks, but all that is Web Development 101, and even other government websites that do the same thing seem to work without a problem. I estimate the HealthCare.gov site could have been written in no more than 5000-6000 lines of code using existing open-source frameworks (and that's being generous).

Perhaps, but how confident are you that you can say the data in such a DB is valid? [IIRC, there's stuff in ACA about mandating electronic medical records.] Moreover, how much would you want to be forced, under penalty of law, to use a site that isn't actually validated? Howabout submitting sensitive medical data, upon which your life may one day depend (drug allergies, perhaps)?

I don't like that idea.