The HRA reliability survey is based around the idea of measuring HRA’s BEST POSSIBLE performence as meaasured by number of failures the system produces over a given amount of time. The data will be used to give researchers, activists and others the raw objective data needed to make their cases against HRA. In other words despite the methodiology being friendly to HRA the purpose of the survey is not. Namely we seek to prove HRA is fundimentally unreliable for it’s intended purpose by showing that even by giving it ever conceivable benefit of the doubt it still fails the definition of reliablity used in systems engineering for being the minimally acceptable reliablity (by more then a few orders of maginitude). And thus have a solid case for asking for common sense reforms.

Assumptions about HRA and failures made in the research/survey:

1. All failures are resolved instantly (in less then 1 second of their occurance) [disproven already by worked example]

2. All failures happen completely at random and are not connected in any manner [disproven already by worked example]

3. That the statistical model used to the study is most favorable to HRA (using Poisssion probablities instead of “straight” long division for example)

4. All rounding, guestimates, etc. are done in HRA’s favor

Sponsor of research: Unsys Labs
Affilition to HRA: NONE
Affiliation with any HRA adjcaent group: NONE
Affiliation with any research insitution: NONE
Citzen Science: YES!!!

Data collected and privacy:

Only the numbers needed to compute system wide MTBF and identify how each borough fairs are collected. No PII (Personal Idetifing Information) like name, case #, address, phone, email ARE NOT collected or stored. Additional steps are taken to obsecure any thing that might be indirectly tracable to any given indivual. For example thes database record is in a flat file (one record per line) with the following format

recordId::personalMTBF::borough

for example the creator of this survey’s record: (note format varies slightly due to limits in markdown parsing)

fe3811892ff0a784440a4e4abc1135c4::125::Queens

(MTBF is the field value over 100 [floating point])

The record ID is generated in the following manner so that it produces a record the creator of the record can claim but reveals no PII.

hash=MD5 recId=hash(salt+fails+years+borough+salt)

Ex. my record ID is salt+8+10+Queens+salt (and no don’t ask what my salt is)

In future versions of the survey we will automate the claiming process

Mathimatical/statistical inputs and assumptions:

Total NYC populat on EBT: 1,800,000 (OTDA)

Total NYC population on SSI: 342,837 (OTDA)

Est. of how many times more complex a SSI case is then an EBT case: 5x

Justification: Sum of the total number of types of benefits being provided. This number is certainly giving HRA the benefit of the doubt in “big-O” growth.

Total est. case load: 3,514,185

Input to system MTBF math: Mean personal MTBF

Math procedure

Step 1: Compute the possion probality ${\mathrm{1-e}}^{\mathrm{-1/MTBF}}$ for failure in one year

Step 2: Multiple step 1 by the total case load to get total fails per yer

Step 3: MTBF = period/fails (period=numebr of seconds in one year)

Notes: Any record with a mathimatical impossible (“0”) value for MTBF will be excluded under the assumption that attempting to compute it produces a divide by 0 error. Due to HTML form design this only possible for the fails part of the MTBF formula. But still displayed as a seperate line item in aggregate reports.

About the author of the study: Over 30 years experience in system performence and reliability roles for life critical systems in the areas of healthcare and internet infrastructure R&D.