The UDS TSG seems poised to take up the task of revising the existing UDS standard. For those not familiar with the layout of UDS, they are fixed width, position delimited files, like you’d typically find on old mainframe type systems. They are not easy to work with and virtually impossible to modify. It’s not a stretch to say that the process of modifying a UDS file is nearly as complicated as completely revamping the standard because each row in a UDS file is a fixed length. Adding an additional field or increasing the length of a data element “breaks” any existing validation processes. Not only that, but any data that is longer than the spec allows gets lost/truncated. If a field is 30 characters long, but the data you want to put into it is 65 characters long, you’re going to lose 35 characters. There’s simply not a place for this data to go. The structure also has the unintended consequence of making UDS files virtually impossible to read and understand without a program to parse them for you.
Here’s a dummy A record we created for automated testing of the UDS Data Mapper:
HEADER02 55555AIN01IN99210201205082012050820120508P&CN
A55555IN99135005111111 1234567 Joe Blow foo 3829 Coconut Palm Drive Indianapolis IN46201000020090622200805012010011800001Blow Joe 285 Fishpond Road Chicago IL606010000S12345678910000001200098+ 8UU 309 19990304 N 90 28 UBale of rags fell on employee, knocking her down,landing on top UU
A55555IN99105010222222 1234568 John Smith foo 3829 Coconut Palm Drive Indianapolis IN46201000020090622200805012010011800001Smith John 2709 Rifle Range Rd Chicago IL606010000S98765432110000001200098+ 8UU 309 19990304 N 90 28 UBale of rags fell on employee, knocking her down,landing on top UU
A55555IN99105010333333 1234569 Ralph Steadman foo 129 E Springbrook Dr Indianapolis IN46201000020090604200805012010011800001Steadman Ralph 285 Fishpond Road Chicago IL606010000S23456789010000001200098+ 8UU 312 19990304 N 61 52 UClmt stacking 2330 lb boxes up to the ceiling and felt pain in UU
A55555IN99105010444444 1234560 Bob Dylan foo 511 Benjamin Way Suite 113 Indianapolis IN46201000020090604200805012010011800001Dylan Bob 204 Nelsay Street Chicago IL606010000S34567890110000001200098+ 8UU 329 19990304 N 42 52 UCart ledged on trailer, while pulling on it, pulled musle in bac UU
A55555IN99105010555555 1234561 Django Rheinhart foo 511 Benjamin Way Suite 112 Indianapolis IN46201000020090606200805012010011800001Rheinhart Django 4403 Davidson Road Chicago IL606010000S45678901210000001200098+ 8UU 329 19990304 N 35 10 UWhile unloading trailer, a cart became loaded while attempting t UU
TRAILER 55555AIN01IN99210201205082012050820120508P&C00000000500000006000490+
Even knowing the UDS spec, it’s hard to tell what’s going on here. You really need a piece of software to break up the elements and tell you what’s what. Now, let’s contrast this with how this file might be represented in JSON:
{
"record_type": "A",
"naic_number": 12345,
"fund_location": "IN",
"fund_type": 10,
"date": 20190214,
"coverage_code": [965005, 965010], //array of coverages
"insolvent_company_claim_num": 123456789,
"receiver_claim_number": 88888888,
"insured":{ //insured structure encapsulates all the insured info in one place
"name": "Bob Smith",
"phone_number": 3175551212,
"insured_address": {
"street_address": "1234 Fake St.",
"city": "Indianapolis",
"state": "IN",
"zip": 46202
},
},
"policy_number": 99999999999,
"date_of_loss": 20190101,
"policy_effective_date": 20190101,
"policy_expiration_date": 20191201,
"claimants": [ //this is an array of claimants - no more counting claimants!
{
"name": "Ralph Steadman",
"claimant_address":{
"street_address": "1234 Vegas St.",
"city": "Indianapolis",
"state": "IN",
"zip": 46202,
"birth_date": 20000101,
"ssn": 1234567789,
"coverages": [965005]
},
},
{
"name": "Inigo Montoya",
"claimant_address":{
"street_address": "1234 Princess St.",
"city": "Indianapolis",
"state": "IN",
"zip": 46202,
"birth_date": 19900101,
"ssn": 1234567789,
"coverages": [965005, 965010]
},
},
{
"name": "Robert Zimmerman",
"claimant_address":{
"street_address": "1234 Desolation Row",
"city": "Indianapolis",
"state": "IN",
"zip": 46202,
"birth_date": 19900101,
"ssn": 1234567789,
"coverages": [965010]
},
}
],
"claim_reported_date": 20190130,
"transaction_code": 123,
"transaction_amount": -12345.00,
"catastrophic_loss_code": 1234,
"recovery_indicator_code": 88888,
"pending_litigation": "Yes",
"second_injury_fund_indicator": "N/A",
"tpa_claim_number": 11111111,
"issuing_company_code":,
"wico_data": { //struct for encapsulating all the wcio data in one location
"injury_code":,
"part_of_body":,
"nature_of_injury":,
"cause":,
"act":,
"type_of_loss":,
"recovery":,
"coverage":,
"settlement":,
"vocational_rehab":
},
"wcab_number": ,
"employer_phone": 3195551212,
"miscellanea": {
"cell_phone_number": 123456789,
"bank_info": "Chase",
"maiden_name": "Karamazov",
"location_of_goonie_treasure": "-77.0364,38.8951",
"tpa_name": "Pat Nat",
"tpa_location": "Florida"
},
"description_of_injury":"Lorem ipsum dolor sit amet, blandit persecuti eu cum, ne usu magna delicata consulatu. Elitr aperiam aliquid at eam, eu integre tractatos pro, ut diam debitis eos. Pro sint nobis vitae cu. Atqui lucilius iudicabit qui in.
In verear vituperata mea, sea ea aperiri vulputate. Dicat accusata inciderint cum te, brute euismod iudicabit vim et. Id quodsi disputationi cum, et adipiscing incorrupte per. Ancillae detraxit in eum, usu exerci dicunt ex, bonorum appetere democritum nam an.
Ex zril cotidieque has, eum ex vero legimus, nam iudicabit instructior eu. Ei sed altera suscipiantur, ubique noster an sed. Mei ne putant nostrum, et has causae eripuit. Sale graece antiopam ea mel. Cu verear habemus dignissim duo, ei omnes tibique mei.
Posse sonet qui ea, at nihil utinam maluisset sit. Nam posse intellegat ex, utamur probatus aliquando et per, mea oratio adolescens no. Mazim omnesque accusata eu has, ei quidam percipit interpretaris nam. Eius principes consequat no nec, graeci vivendo an sit, eum diam debitis explicari ut. His sint postea minimum ne. In modo alienum nec, mel sapientem forensibus te, ut audiam conclusionemque has.
Doctus efficiendi per ei, duo ad altera tractatos urbanitas, sed posse viris erroribus id. Ea saepe omittam iracundia mel. Nec ex facer neglegentur, in has quot verterem voluptatibus. Vim purto menandri et. Sed oporteat sententiae at, at omnis nominavi nec, nam purto habemus ne. Sed laboramus instructior voluptatibus ad.",
}
That’s a lot clearer. Everything is defined for you in a series of name/value pairs, so you know what data are what. It’s also not limited by length, so the full accident description and other fields that are typically longer than the UDS spec contemplates don’t get lost. Also, we’re able to encapsulate data that goes together: all the claimant data is in one block, addresses are consistently represented irrespective of who’s address it is, and data are nested instead of denormalized. Finally, perhaps the most exciting feature is that there’s a section for miscellaneous data not contemplated by the spec. Virtually anything can be added in there and it won’t break the spec. If you want it, it’s there. And if not, it can be ignored.
This is a clear win over the existing spec. I know adoption won’t be easy – all the funds and liquidators will have to change their systems. But I think the improvements are worth the investment. UDS, in its current incarnation (fixed files) is over 20 years old. It’s in dire need of a facelift.
Dumping archaic systems and standards is never easy and often viewed from a “cost” perspective. As forward thinking leaders, we need to consider the benefits that cannot yet be quantified and the opportunity cost of not effecting change. We must consider whether the current industry standard data model delivers the kind of value that aligns with our objectives or whether it’s time for change. Thanks for a good explanation in layman’s terms of the limitations and alternatives.