At 02:21 PM 08/28/2002 -0700, Bish wrote: >wwvierg@ATTGLOBAL.NET (William W. Viergever) wrote in message >news:<5.1.0.14.2.20020823160639.00ab0c18@pop3.attglobal.net>... > > At 10:45 AM 8/23/2002 -0700, Bish wrote: > > >Hi all...this is the first time I've posted on this board, and I'd > > >like to make an introduction :) > > > > > >I'm fairly new to SAS and the HealthCare Industry, but day by day > > >things get a bit easier. > > > > Day by day we get smarter. > > > > >I have a tendency to be active with good community boards and try > > >to contribute as much if not more than I recieve. > > > > I contribute more wine than I drink ... usually <g> > > > > >I've recently be presented with a project that involves converting > > >flat files recieved from the State that were created under HIPAA 835 > > >requirements. > > > > Who bid this project? ... you, an employer? ... where are/were the job > > specs or RFP? > > > > >Now typically, this wouldn't be a big deal b/c I could > > >simply look at the spec for the files being sent and import the > > >information then format it into a workable SAS dataset. The problem > > >is that the state will not supply a spec or sample text file for us to > > >work with...likely b/c they haven't gotten the thing put together yet > > >:) > > > > > > I'm assuming you mean they haven't written a set of user docs/data > > dictionary/layout/etc. for this 835 data; I've had similar experience > > getting data before docs were ready - from the state of Calif. > > > > In which case, see if they can provide you w/ the COBOL (most likely) > > program that created the data tape w/. That *may* provide you w/ enough to > > write a SAS input statement .... > > > > On the otherhand it probably will not, for the nature of the 835 data is > > one of many small "segments" that are part of bigger "records" (or > > "transaction sets"), and the COBOL pgm wll probably simply say it's > > bringing in *something* from way over here and writing it out, way over > > there in such & such buffer <g>, i.e., you still won't know what's in that > > particular "something", field-wise. > > > > Bottom line, you will most likely have to pour over the Guidelines for the > > "835: Health Care Claim Payment/Advice" files, see: > > > > http://hipaa.wpc-edi.com/HIPAA_40.asp > > > > and construct your own set of input statements for the HEADER, DETAIL, and > > SUMMARY segments *and* all their variants and "loops". > > > > In particular, you'll need to go through the entire Appendix A, the "ASC > > X12 Nomenclature". > > > > Note: This stuff ain't easy; it's why folks are charging BIG BUCKS to do > > HIPAA stuff. Get ready for a slew of conditional INPUT statements -- > > trailing @ signs, baybee! > > > > Implicit in all this is how you will plan your SAS dataset(s); i.e., what > > is the "unit of observation" that your desired SAS dataset(s) will have? > > ... claim level?, line item? ... provider level? ... i.e., as you read > > these data from the flat files, how do you want to output them? > > > > This issue is pervasive in the health care data world, and as the MVS-Maven > > Mmmmiiiikkkkeeee pointed out, is addressed nicely in the Scerbo, Dickstein, > > & Wilson's BBU: "Health Care Data and the SAS System". > > > > If you score this book (recommended), pay attention to their "Chapter 3 > > Data Forms, Layouts, and Files" and "Chapter 7 Combining the Data" where > > they get into data structures and terminology. > > > > Unfortunately, HIPAA is relegated to their "Chapter 10 The Future of Health > > Care Data" so you'll probably not find anything canned. > > > > > > >Anyway, we know that the State will likely run us pretty much out of > > >time before we get what we need..so we want to get a jump start on > > >them. Has anyone out there had to recieve remitance files from the > > >state that follow the HIPAA 835 guidlines, and then convert those > > >files into a SAS dataset? If so, would you be willing give me a nudge > > >in the right direction? > > > > See nudge above. > > > > >About all I have for resource materials are SAS and the Health Care > > >Claim Payment/Advice 835 tech manual. > > > > Repeat 10 times ... real quick: X12, X12, X12 ... > > > > > > >Thanks, > > > > Good Luck > > > > ------------------------------------------------------------ > > William W. Viergever Voice : (916) 483-8398 > > Viergever & Associates Fax : (916) 486-1488 > > Sacramento, CA 95825 E-mail : wwvierg@attglobal.net > > ------------------------------------------------------------ > > -- > > >William, > >you're too funny :) and too correct too. I've burried my face in >this Health Care Claim Payment/Advice (835 ASC X12N) pub and am >chugging along. As you mentioned, I've spent a good deal of time in >Appendix A...but the one thing I'm absolutly not getting is THE BIG >BUCK TO PUT THIS TOGETHER! hehe > >anyway, I've ripped out a couple sample transactions from the manaual >and will using them as a baby sample. The State has hired EDS to set >up the transmittal from their end, and we're not expected to see >anything until next Oct. sometime, so this is gonna have to due.

Have dealt w/ EDS; it was like pulling teeth to get any docs from them ... and if you wanted any custom programming (e.g., data extracts) they charged ... well like the $600 Navy toliet seats ... if you catch my drift.

>Well..thanks for the laugh, when

*when* is good ... *if* is bad <g>

>I get this done (I have this project >and a few others...so it will take at least a month or so) I'd be >happy to distribute it for use and refinement.

Be happy to take a look at it; and won't even charge you <vbg>

> Or hell...maybe I'll try to sell it :)

If it works, you should ... assuming you able to keep rights to your code on this project.

>Wave,

Join the Navy and ride the ...

>Bish

------------------------------------------------------------ William W. Viergever Voice : (916) 483-8398 Viergever & Associates Fax : (916) 486-1488 Sacramento, CA 95825 E-mail : wwvierg@attglobal.net ------------------------------------------------------------