stuck: Is There A Problem Here?: stuck

20131117

Problem ID: 6540715378706480415
Entered by: Ben Simo

Healthcare.gov can't handle application edits

One of my Healthcare.gov application attempts has been stuck for two weeks. Each time I attempt to resume filling out the application, it prompts me to answer a couple questions and then gets stuck on a "Please wait" display. This message stays on the screen until the session times out.

Chrome's console shows me that there is an uncaught Javascript error that is preventing me from completing the application.

This error is occurring in code that appears to be attempting to retrieve the name of someone on my application.

A member.personName object in my application is null. The code is expecting that this contain elements named firstName and lastName and suffixName.

So, why does my application contain people filled with null values? Early in the application process, I was getting a similar error message. I deleted some people from my application using the provided user interface and was able to get further into the application process.

It appears that those deleted family members were removed from the application but the data structures in which their data was stored remain; filled with null values and empty arrays. It appears that the application is now getting stuck on those deleted family members.

And, now that I'm further into the application process, the options to add the deleted family members back into the application is no longer available.

Did the developers of Healthcare.gov not anticipate that someone might use the features they provide to remove people from an application? Did the testers not try entering and then later editing data entered into an application?

Although I don't really know what testing was or was not done, I can't help but think that no one strayed off the happiest of paths as they tested this.

Edit

20131110

Problem ID: 3140808259759357651
Entered by: Anonymous

Healthcare.gov clones children

Gary reports:

My problem with the Healthcare.gov site is somewhat complex and not something I have heard of in the many reports of failures:

I have successfully completed registration and all of the steps up through to reaching the "to-do list".

Problems I've encountered (I will try to keep them in order as I proceed through the process):

Here is where "viewing my application" lands me:

The first sign of trouble is that under "app details" in the right column, I get no response when clicking "view eligibility results".

On the same page, I have "discrepancies" and have successfully submitted the documents they request though I have not received any confirmation that the inconsistencies have been resolved:

Going back to "resume enrollment" and clicking on that I am taken to my "to do list:

This page is where the real trouble is. Everything is fine down through "select insurance 1". I have successfully chosen my desired plan.

Here's where the bizarre begins:

Note that I have 3 subsequent tasks, all requesting I set insurance for the same child, Kevin, who IS included in the plan I chose in "plan 1".

Under "plan 2" I have gone to the page to pick insurance and NOT made a choice. That has cleared the task.

Under plans 3 and 4, however, clicking on "set" takes me to a page that is blank. It does not show any plans from which I can choose. And on returning to the to do list the tasks will not clear:

I am presuming the dental plan and review/confirm tasks will remain locked until I clear plans 3 and 4.

I had hit an identical roadblock prior to one of the maintenance outages except it happened at the "dental" step. At the time I did NOT have the redundant insurance steps 2,3,4. I was able to choose my family health plan and proceeded to the next step which was, as expected, "dental". However when I clicked on dental I got the same empty page as I am getting now for insurance 2,3.

I doubt you can help me, but hope my experience helps you as you continue working to improve the site functionality.

Gary has reached a point in the application process that I (Ben Simo) have not been able to reach. However, I suspect that the cause of his problems is similar to that of some applications I have in a stuck state from which I cannot continue.

The system appears to send the entire application data set back and forth between the applicant's web browser and the Healthcare.gov servers throughout the application process. Most of the processing (except for the retrieval of data from back-end systems) appears to occur in the web browser rather than on the server. I have seen data get into a state that the client-side Javascript code cannot execute. In the cases I've encountered, the browser encounters errors but fails to display this to the user. The most common error I've seen is the Javascript attempting to apply string methods to null values. (And, I have observed empty strings get transformed into null values as I progress through an application.) For the non-technical: a null value is a value that doesn't exist; one that the Javascript software running in each user's web browser treats differently than an empty or blank value.

When an application gets into this kind of state, chances are that the applicant will need to start over -- or wait for the Healthcare.gov developers to not only fix the issues putting applications into bad states; but also fix handling of applications that are already in a bad state.

Do you have an application in a bad state? Please share it with us.

Edit

Usability Heuristics

• Visibility of system status Visibility of system status: The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

• Match between system and the real world Match between system and the real world: The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

• User control and freedom User control and freedom: Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

• Consistency and standards Consistency and standards: Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

• Error prevention Error prevention: Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

• Recognition rather than recall Recognition rather than recall: Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

• Flexibility and efficiency of use Flexibility and efficiency of use: Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

• Aesthetic and minimalist design Aesthetic and minimalist design: Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

• Help users recognize, diagnose, and recover from errors Help users recognize, diagnose, and recover from errors: Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

• Help and documentation Help and documentation: Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

Consistency Heuristics

-F amiliar Familiar: The product is not consistent with the pattern of any familiar problem.

E xplainable Explainable: The product is explainable.

W orld World: The product is consistent with the real world.

H istory History: The present version of the product is consistent with past versions of it.

I mage Image: The product is consistent with an image that the organization wants to project.

C omparable Products Comparable Products: The product is consistent with comparable systems.

C laims Claims: The product is consistent with what important people say it’s supposed to be.

U ser Expectations User Expectations: The product is consistent with what users want.

P roduct Product: Each element of the product is consistent with comparable elements in the same system.

P urpose Purpose: The product is consistent with its purposes, both explicit and implicit.

S tatutes Statutes: The product is consistent with applicable laws.

FAILURE Heuristics

F unctional Functional: The error detecting, reporting, and handling functions properly.

A ppropriate Appropriate: Errors are reported at the appropriate time in an appropriate manner.

I mpact Impact: The impact of the failure is communicated to those impacted.

L og Log: The error is appropriately logged; or not logged.

U ser Interface User Interface: The error is reported in the user interface in terms that the user understands.

R ecovery Recovery: The user is informed of what they need to do to recover from the error.

E motions Emotions: The error handling and reporting has a positive influence on user emotions.

Security Vulnerabilities

1. Injection Injection: Injection flaws occur when untrusted data is sent to an interpreter as part of a command. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without authorization.

2. Broken authentication and session management Broken authentication and session management: Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

3. Cross-Site Scripting Cross-Site Scripting (XSS): XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

4. Insecure Direct Object References Insecure Direct Object References: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to gain unauthorized access to data.

5. Security Misconfiguration Security Misconfiguration: Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

6. Sensitive Data Exposure Sensitive Data Exposure: Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

7. Missing Function Level Access Control Missing Function Level Access Control: Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.

8. Cross-Site Request Forgery Cross-Site Request Forgery (CSRF): A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

9. Using Components with Known Vulnerabilities Using Components with Known Vulnerabilities: Running software components with known vulnerabilities can compromise the vulnerable components and anything those components can access -- undermining defenses.

10. Unvalidated Redirects and Forwards Unvalidated Redirects and Forwards: Using untrusted data, without validation, to determine the destination of redirects and forwards can enable attackers to redirect victims to phisihing or malware sites.

Is There A Problem Here?

20131117

Healthcare.gov can't handle application edits

20131110

Healthcare.gov clones children

Problem or no problem?

Usability Heuristics

Consistency Heuristics

FAILURE Heuristics

Security Vulnerabilities

Popular

Recent Problems

Recent Comments