Ordered timestamps to test a clocktime measure (OFFICE 97 SR2)

Topic

New Reply

Hi:
Here is a little background to my problem. Our Medical Record Abstractors generate datetime Stamps, to a Tracking database application, for two events for each Medical Record that they abstract: an abstraction Start event and an abstraction Completion event. The data base application which stores the data generated by the Abstractor also produces a variable, which we call

Reply | Quote

Replies

Instead of trying to fiqure out a more complex query, why not query for all records where the “Revtime” is too large, then compare this to the records from the query you already wrote (the one that finds records where no other record was started). If you compare the two results, you will see that any records in the new query that are not in your previous query, would be the records that you are looking for.

Reply | Quote

One more thought. You only say that some of the “Revtime” values are incorrect, so I assume the timestamp values are correct. If the timestamp values in a record are correct, and the formula that generates the “Revtime” is correct, then I think it may be that when the formula actually runs, it is using incorrect data sometimes(possibly due to stopping, starting?). What I’m saying is this: If you have correct data used as input to a valid formula, the results should always be correct. If this “Revtime” is generated on the fly (during data entry); something must be feeding incorrect values to the formula, even though correct timestamp values are being saved. Could the process that generates the “Revtime” values be separated from the rest of this process and run at a later time? In other words, could you create the “Revtime” values as a “batch” process using only completed records as input, instead of these values being created during data entry?

Reply | Quote

Willyboy:
I found out a little more today. It appears that our Abstractors are able to place a case on “Pause” and open another case. So, someone could start a case at 10:00 AM, place it on Pause at 10:04 AM and immediately start another case. We did not know this before. So, I am kind of putting the queries on back burner until we can run some experiments and see what the impact they have on these measures.
Thank you very much for your responses. In case I have to come back for more advise on this one, however, let me make a comment regarding your suggestion:
“why not query for all records where the “Revtime” is too large, then compare this to the records from the query you already wrote (the one that finds records where other record was started).”
That is what I was trying to do – design a query that would catch more cases where the Revtime was too large. I do not think we will ever be able to identify all cases. For example, if a case is left open a day, the next tracking event that we get is the time it was finished. Even if it was the first case finished on the next day, say at 10:00 AM, and the person came to work at 8:00 AM, we would not know whether he was in this case for 2 more hours because our system does not record the re-start time. And, even for cases completed later the same day, you have to know to how much time to subtract from the (completion timestamp – start timestamp) measure in order to account for these other cases. In order to do this you have to assume that the Revtimes for these cases are accurate. Finally, designing a query to identify all the different scenarios (or even a few of them) would be a major task (for me, anyway). You would need to do this in order to determine the prevalence of the error cases among all cases that fit the pattern. I think it is going to more productive at this point to do what we should have done several years ago and that is to test these systems using several of the suspect scenarios.
Thanks again for you help. Maybe I will Post again if I find out anything that might of interest to other loungers.

Reply | Quote