MU2 Progress

bradymiller wrote on Friday, February 12, 2016:

Devs(or somebody with very deep knowledge of the feature) can also help when explaining functionality to Milton during the testing(it’s not just about passing the testing scripts; there are also expectations by Milton which are not documented in the testing scripts).
-brady

tmccormi wrote on Friday, February 12, 2016:

Brady has very specific experience with that now :slight_smile:

teryhill wrote on Friday, March 11, 2016:

I really hate to keep beating this horse but I want to make sure it is not DEAD, is there any progress on this?

Terry

bradymiller wrote on Friday, March 11, 2016:

Things are moving, but really, really slow. Plan to discuss ways(ie. money) to try to speed things up at next OEMR meeting this Saturday.
-brady

fsgl wrote on Friday, March 11, 2016:

It’s moribund alright.

Join the conference call, March 12th, 2 p.m. EST.

You can help do CPR on the poor creature (not joshing).

tmccormi wrote on Saturday, March 12, 2016:

Attached summary of measures ready to cert and those not … etc

bradymiller wrote on Sunday, March 13, 2016:

Hi,
I updated the MU2 barometer using the above document provided by Tony:
http://www.open-emr.org/wiki/index.php/OpenEMR_Certification_Stage_II_Meaningful_Use#Completion_Barometer
-brady

harleytuck wrote on Thursday, March 17, 2016:

G3 update:

For those who don’t know, a couple weeks ago Milton sent along some new, improved and expanded requirements for the G3 Usability report that V. Lorenzi at Columbia U had created with her Health Informatics students last year. Come to find out, the report has to be re-done to conform with the new requirements.

Ms Lorenzi agreed yesterday that she would engage her current crop of students and re- do the report. She’s having them start on it this Friday and seems eager to gitter done.

All Hail Virginia, OpenEMR Elf-Friend!

  • HT

tmccormi wrote on Thursday, March 17, 2016:

Jacob sent the HL7 for f(3) and the WCAG file for e(1). So those should be good to go.

harleytuck wrote on Thursday, March 17, 2016:

I’m lining up the next/ last(?) push at b5a lab testing; haven’t heard from Milton yet though.
Any devs want to join the test session?

This just in- Milton asks:
“Does Tuesday afternoon work for you? 1:00pm – 2:00pm PDT?”

sunsetsystems wrote on Thursday, March 17, 2016:

I will be away Monday and Tuesday, but can be available after that in case anything comes up. Main thing though is to go through all the test cases in advance and make sure the required results are met… and make sure you can clear the data and do it all again. :slight_smile: It’s probably not workable to fix a bug during a formal session.

Rod

harleytuck wrote on Thursday, March 17, 2016:

Hi Rod-
Yes, I concur re: the bug fixing.
I’ve made 3 successful dry runs through the testing steps today, including the previously problematic steps. I have good hopes for the real thing.

  • HT

bradymiller wrote on Friday, March 18, 2016:

Hi Harley,

Is there an approximate ETA on when the G3 item may be completed?

thanks,
-brady
OpenEMR

harleytuck wrote on Friday, March 18, 2016:

Last I spoke with her she was still uncertain how many people she could involve, just that she was agreeable to the project. And it was supposed to start today so she may have some better ideas after it gets rolling. I’ll touch base with her early next week and see how it’s going.

  • HT

harleytuck wrote on Wednesday, March 23, 2016:

Hi Folks-

Milton and I had a productive though puzzling session today testing b5a labs. Most of the lab objectives seem to have been passed but he halted the test til we could check out some oddities that occurred.

The first time we went through the tests we downloaded all the LRI files at once then looked in the EMR to see that they had been processed correctly.

The first time that file LRI 1.1 was processed it looked like pic 1.2b, except it showed 5 copies of the same ‘Final’ line without the ‘Corrected’ line with the red ‘High’.
Later we dloaded that file again and it shows what you see. So Milton asked why multiple duplicate lines were present.
Still later I went back myself and got the file again, and it had (only) 2 duplicate Final lines and the Corrected red ‘High’.

As far as Milton and I could tell the LRI site seems to have downloaded corrupted files in some cases: we dloaded the same file a couple times and they had different data in them- different pt names, tests, etc. So we had to get the file again, visually look to see it was correct then check it in the EMR. Which is our plan for this coming Friday at 3:30: individually check each file as it’s downloaded and imported into the EMR, then do the next.

The only corrections he says are needed are the duplicate lines mentioned above, and for a policy decision to be made: does the EMR need to show the time in the timestamps? If it does, the time zone must be displayed. If not, remove the times and just show the date.

More Friday. Rgds- HT

sunsetsystems wrote on Wednesday, March 23, 2016:

Harley, I don’t think you are sufficiently clearing out the patient data between test sessions. See my posts about that in the previous page of the thread and especially note the part about deleting patients and not just tables.

As for timestamps, the juror documents show them like this:

Thu Mar 31 14:05:51 GMT-08:00 2011

We show them like this:

2011-03-31 14:05

I don’t think it’s logical to omit the time portion. And even if we did, time zone affects dates as well as times. Are they really going to fail the test because of a missing time zone??? Surely it’s reasonable to assume that the date/time is what is local to the lab.

I can add the “GMT-0800” but I think it’s wrong to have this useless clutter, and I’m really pissed that it’s only being brought up now after many rounds of testing with timestamps in plain sight.

Rod
http://www.sunsetsystems.com/

mdsupport wrote on Wednesday, March 23, 2016:

Agree with Rod regarding display of non-medical information in a medical records system.

May be they can accept tracking information as part of notes where date and lab’s result tracking information can be printed only once per report.

harleytuck wrote on Wednesday, March 23, 2016:

Hi Rod-
I’ve been clearing the system by deleting the 3 lab- created patients since you recommended it, and either using the truncate or your delete tables commands. They both do the job equally well.

Today I cleared the system, re- downloaded and processed the LRI files again, The file that had those oddball duplicate lines yesterday displayed properly today, so I’m sure it’s not your code. The LRI site has been behaving badly these past couple days so on Friday we’ll just go slow and make sure we get good data files.

As far as the ‘reasonable’ assumption, that’s a null statement for this MU testing project, isn’t it? As you demonstrated, the difference between what OpenEMR displays and what the juror docs show is the time zone. Milton says we can match the juror doc or simply not show the time. My vote, for what it’s worth is to chop off the time. As you point out, it’d tidy up the displays a lot and that’s worth something.

As far as the other, I guess I’ll just choose to conserve my bodily fluids.

Oh, yes- on a tangentially related matter, I also asked Milton if he had any help documents for CDS, AMC and CQM such as he provided for g3. He said, no, those measures aren’t as ‘prescriptive’ as g3 is so they haven’t developed that documentation for them.

Hasta- HT

sunsetsystems wrote on Thursday, March 24, 2016:

We don’t store the original time zone in the procedure_result or procedure_report tables. That is not normal practice when recording timestamps of events because it complicates queries that care when something happened. I suspect the “right” thing to do is store report date/time and collection date/time as GMT and display them converted to the current local time zone. If we must repeatedly remind our users what time zone they are in, so be it. Is that acceptable?

It would certainly be easier to just truncate the time portion. But isn’t sample collection time sometimes important clinical information? I am very reluctant to remove it if it is.

Rod

bradymiller wrote on Thursday, March 24, 2016:

yes, sample time can be important(just like in vitals) esepcially if checking same lab over same day; a recheck of a CBC before and after a blood transfusion would be one example.