STS v.2.73 : A Tale of Two Cities…

(Click Image to View STS Website)

A series of STS Updates and Insights:

The Society for Thoracic Surgery (STS) national cardiac database is the all-consummate monster of consolidated data requirements that most cardiac programs subscribe to.

To be left off of the report card, is to be isolated and not assembled for review on the national slate, and that can be financially devastating as well as have serious implications as to what range of procedures your institution will ultimately be allowed to offer it’s client population (the patients).

The Two Cities… The Update to v.2.73

Well this is the first official update on what is proving to be a difficult migration to version 2.73.  That includes clinical managers, perfusionists, Quality Management, software developers, and the vaunted Duke University data machine.

The issue at hand is how to integrate 700+ new data fields into an existing structure (more than doubling it in size) accommodate the needs of various institutions who don’t wish to just abandon older data from previous versions, and at the same time maintain a familiar GUI (front end) for data managers to enter data.  Nobody really knows if and how smoothly-  this process is going to work.

Man creates machine, machine re-tools man… or something like that.

This post will be a running day-diary of the last official day for STS data uploads to the national database.  It has already been a trial (more on that later through the day) and STS has already extended the deadline by one day for data submissions (unheard of prior to today).

I am off to resubmit data for the 12th time in the last 6 days.  I’ll be back as soon as I get to the hospital computer and make my next attempt.

Update:  The Next day

Ok.  So I was going to keep uploading STS files with corrections, until I had it perfect.  Unfortunately, what wasn’t perfect was my schedule, an add on emergency of a double valve (MVR/TVR) with severe regurg on both valves, and the mitral valve presenting as an almost complete stone of calcium.  The surgeon said he had to core it out like an apple- it truly was “the worst he had ever seen”, and it led to a pretty long pump run, where all involved felt lucky that the patient came off the table.

It was that kind of case.

No ambiguity, waiting, or rewriting STS code, plain hard facts…  fix it or have a dead patient.  Stats can wait.

It kind of put things in perspective, and when I was done, I left my final submission to STS alone, figured with all  the software glitches- and chaos that I was seeing on my Data Quality Reports- it was out of my hands and now depended on the skill of the software programmer, who had to rewrite a whole ton of code to fix whatever problems had been encountered as a result of this new union of 700 data fields, and new software expectations from the client giant (STS).

Did he get it right?  I don’t know…  But I am sure I will find out in 3 months.

Writing code is probably stressful.  This bypass run wasn’t.  I was back in my comfort zone, dealing with tangibles that I could understand- not SQL.  In this case, I KNOW we got it right.

Some people sleep, and dream in code, I sleep and wake up grabbing a dissolving  pump clamp… (if it’s that kind of dream).

Version 2.73 will have to wait on this day.

Later.

Thanks Tonya S.  for all the help over the last few days.

Frank