When can we release 4.0?

drbowen wrote on Saturday, June 26, 2010:

1. Security and Privacy - 7+/8 finished. 

Recording disclosures.  The patch has been submitted.  A few suggestions were received by Brady Miller and these should be fixed in 1-2 days.  Selvi will need Q/A of the work and will provide access to their test server for this.

2. Computerized Physician Order Entry -  Simone Aiken has been working with Tony on the Physician Order Entry and is especially concerned about improving the work flow for the clinician. 

3. Drug Decision Support -  Just need a hot-link from OpenEMR to e-Rx Now.

There is a working demo of drug decision support at:
http://openemrsupport.com:10080/openemr-drugdb/interface/login/login_frame.php
admin:pass

patient/clinical -> medical record -> Rx -> Add Prescription

This based on a earlier 3.3-dev. I just tested this access and I can see that the drug-allegy checking is working but there does not appear to have drug look-up working.  Perhaps the MySQL engine is mis-behaving.  (Warnings need to be turned off in the php.ini.)

4. Problem List - is done.

5. E-prescribing - Just need a hot-link from OpenEMR to e-Rx Now.

The administrative functions of e-prescribing are at:
http://openemrsupport.com:10080/openemr-surescripts/interface/login/login_frame.php
admin:pass

Administration -> users

6.  Medication List - done. 

7. Medication Allergy List - done.

8. Demographics - waiting on code submission to CVS.  I think this is done.

9. Vital Signs - done

10. Smoking Status - done.

11. Lab Test Results - code committed.   Q/A and testing are in progress

12. Patient Lists - Thomas Wong has been through a couple of cycles of QA work with Visolve and believes this will be completed within one week.

13.  CMS Quality Reporting - The 5 report have been written.  The “Intermediate Final Rule” has just come out last Monday.  The current 5 reports may be sufficient to pass Meaningful Use.   These regs are in flux but seem to be solidifying.  Thomas will continue his review and report back.

QA assigned to Visolve.

14. Patient Reminders - Tied in with the Clinical decision rule.  About 20-30 hours of coding is left before this is finished,

15. Clinical Decision Rule - Tied in with the Patient reminders.  About 20-30 hours of coding is left before this is finished.

16. Insurance Eligibility - PhyAura has delivered code.  Michael Brody has a developer working on an alternative solution and believes this will be done in 7-10 days.

17. Electronic Claims Submission - This is working in multiple clinics.  QA by Tony McCormick and Garden State pending.

18. Patient Electronic Copy of Health Information - Not done

19. Patient Electronic Access to Health Information - Not done

20. Patient Clinical Summaries -  Not done

21. Exchange Clinical Information - Not done

22. Medication Reconciliation - Verbus Counts. Coding completed waiting on review.

23. Summary Care Record for Transition of Care / Referral - Not done

24. Immunization Registries - Michael Brody.  Plans to start this item when #25 has been accepted and has passed.

25. Electronic Syndromic Surveillance - Michael Brody. Coding completed.  Waiting on Review.  CCHIT has validated that this report passes as is.

Garden State has the CCR working and this drives #18, #19, #20, #21, #23.  He needs assistance with the GUI interface to complete these items.

These are really HUGE improvements and new features in 4.0-devtip.  The modal windows are an issue for me but I have found the 4.0-devtip code quite stable.

Why not release freeze additional features, review/debug the code that already exists and release 4.0 now?

Sam Bowen, MD
http://openmedsoftware.org

blankev wrote on Saturday, June 26, 2010:

Dr Bowen,

if your presumptions are to the point, (who would doubt after such scrutiny,) there is only a very big mountain left to climb.

Who is willing to create the very much needed updated manual?

Can this be done in the same time as it was done for 3.2 with this same great result? With all the new developments it is hard to see where extra explanation is needed.

The Wiki on OpenEMR has to have some major upgrades on explanatory use update as well.

But if all this is not feasible in time, just for me personally, I like 4.0 as is. Please release ASAP.

Pimm

tmccormi wrote on Saturday, June 26, 2010:

Sara at MI2 will be able to do a new user’s guide of 4.0, she can start working on that at anytime.   We do need some help on how some of the new functions work, like Procedures. Messages, etc … she’ll trip on those and then have much better questions to ask when it happens.

-Tony

blankev wrote on Saturday, June 26, 2010:

Please thank Sara for her great understanding and support of OpenEMR. This is great. If you/she need some help please post and I will see if I can do anything.

bradymiller wrote on Monday, June 28, 2010:

Sam,

Rather than dump the MU use progress here, I’d suggest making a developer forum thread entitled meaningful use progress and placing regular MU progress dumps there. This information is generally very useful and enlightening to all developers/users, and would be really nice to have a thread dedicated to it.

Considering majority of these projects are incomplete or already exist in 3.2, wasn’t clear what new features (from your above MU progress dump) would go into 4.0 if we freeze now???

Here are things that likely should be done before fixing the code:
1)  Getting below projects currently in SF review into the codebase:
Patient Lists
Insurance Eligibility
Recording Disclosures

2) Adding links for MU 3 and 5 (if this is indeed all that needs to be done)

3) GUI:
Major feature that has to be added is the modul fix (use percentage of window rather than an absolute size):
http://sourceforge.net/projects/openemr/forums/forum/202506/topic/3751026

4) Security:
Extensive changes in the underlying code, and nice to get some road testing, but no reason for this to delay the freeze:
http://sourceforge.net/projects/openemr/forums/forum/202506/topic/3530656

The above could take anywhere from a week to several months (pretty much dependent on fixing the gui moduls and bugs).

After freeze, then need to do following:
1) Fix a huge number of bugs (see the tracker)
2) Get a translation cycle in (takes about 2-4 weeks for this)

“Why not release freeze additional features, review/debug the code that already exists and release 4.0 now?”…

From my above comments, I would likely define “now” as 9/1/2010. Unless I’m missing something.

-brady

drbowen wrote on Friday, July 02, 2010:

Brady your points are well taken.  I chose to “dump” the progress list here for the community as a whole to be able to see what has actually been accomplished.

While I apologize in advance for not having been able to convert to the 4.0-devtip, we are trying to bring this up live in our office to actually “road test” all of these new features.  We have already had several staff training sessions and a couple of abortive attempts that didn’t last very long (1-2 hours each).  We are continuing our effort to do this and currently we are waiting on Yijin Woo to help us debug the laboratory test result API. (and hopefully the modal windows will be improved soon).

Sam Bowen, MD
http://oemr.org

bradymiller wrote on Tuesday, August 03, 2010:

hey,
Should try to get above stuff in, and consider freezing(branching) of code soon.
-brady

drbowen wrote on Tuesday, August 03, 2010:

We discussed this in the Meaningful Use Project meeting on Monday night.  My concern is that there are so many new features that we need at least an interim release candidate to work out the bugs before the official “4.0” release.  I know there are a number of pieces that are still in progress but if we don’t get some more generalized bug finding done by an increased number of users we’re going to have bigger mess during the the official release of 4.0.

Would you be OK with either

1)remove the modules that are known to be unstable for an interim release

2)Publish an “unstable” version with the code as is.

I think we ought to do this now.  We need to get the new modules into circulation for road testing.

Sam Bowen, MD
http://oemr.org

verbus wrote on Tuesday, August 03, 2010:

All,

I vote for #2 - Publish an “unstable” version with the code as is.

Verbus

bradymiller wrote on Tuesday, August 03, 2010:

hey,
Looked through our 59 bugs, and found at least 10 or so that should be fixed (put them in group “release 4.0.0”):
http://sourceforge.net/tracker/?limit=25&func=&group_id=60081&atid=493001&assignee=&status=2&category=&artgroup=1198495&keyword=&submitter=&artifact_id=&assignee=&status=1&category=&artgroup=1198495&submitter=&keyword=&artifact_id=&submit=Filter&mass_category=&mass_priority=&mass_resolution=&mass_assignee=&mass_artgroup=&mass_status=&mass_cannedresponse=

Last time we published release candidates, it was a complete mess as I recall. We’ve got a good number of testers and bug reports that use most recent code (many available methods to do this here):
http://www.openmedsoftware.org/wiki/OpenEMR_Downloads#Unstable_Development_Releases
http://www.openmedsoftware.org/wiki/Git_for_dummies

Sam, what new modules in the current codebase need further testing?

thanks,
-brady

drbowen wrote on Thursday, August 05, 2010:

The problem with our release cycle is that we don’t have enough testers who are not code experts.  We need less sophisticated users banging at the code in unpredictable less educated ways.  This never happens until after an official release.  The we have to immediately turn around and do a bug fix release.

These modules are listed on the Meaningful Use web page are are discussed extensively every Monday night at 7PM PDT.

These modules are listed as “complete.”  Some of them are old and don’t need much testing.  Others are new with 4.0 and definitely need further debugging.  This is analogous to FDA “Phase 4” drug testing.  When the drugs are released to the general population and the FDA starts collecting incident reports and monitors for excessive problems such as the recent hoorah over Avandia and possible increased risk of heart attack.

Foundations: Security and Privacy
Problem List
Medication List
Medication Allergy List
Demographics
Vital Signs
Smoking Status
Electronic Claims Submission - Not Needed for Physician side Cert

Almost ready to be released:
Lab Test Results (Yijin Woo, Thomas Wong and Intesync, Sunset Systems)
Computer Physician Order Entry (Intesync, Sunset Systems)

These are close but still additional work:
Insurance Eligibility - Not Needed for Physician side Cert  (Phyaura, MI2)
Patient Lists  (Thomas Wong and Intesync)
Drug Decision Support (OEMRS, MI2, Visolve)
Medication Reconciliation (Verbus Counts)

Probably ready, but needs testing, the patient reminders infrastructure is in flux and needs to be stabilized.  MI2 is likely going to take over this public role:
CMS Quality Reporting (Thomas Wong and Intesync)
Patient Reminders (Thomas Wong and Intesync)
Clinical Decision Rules (Thomas Wong and Intesync)
Immunization Registries (Michael Brody)
Electronic Syndromic Surveillance (Michael Brody)

Needs a connector to either AllScripts or to Phyaura.  A more permanent direct connection to SureScripts will take many months:
Electronic Prescribing  (MI2, OEMRS, Visolve, Michael Brody)

Coding in progress (Thomas Wong and Intesync, Garden State Health):
Patient Electronic Copy of Health Information (estimated time to delivery 4-6 weeks)
Patient Electronic Access to Health Information(estimated time to delivery 4-6 weeks)
Patient Clinical Summaries (estimated time to delivery 1-2 weeks)
Exchange Clinical Information (estimated time to delivery 1-2 weeks)
Summary Care Record for Transition of Care/Referral (estimated time to delivery 1-2 weeks)

Sam Bowen, MD
http://oemr.org

bradymiller wrote on Friday, August 06, 2010:

Sam,

I’d argue that since changing to the branching/patching scheme, we have not had to issue a bug fix release. We also have a mechanism to easily fix bugs (and provide new features) via patches (the limiting factor in the patches is that it can’t modify the database, which is why I’m so particular about not introducing bugs into the database files). This scheme has allowed us to create online demos to get the code tested along with daily releases after a branch release freeze.

Was hoping to get a simple answer for what modules are currently in the codebase that need testing(ie. if we freeze code today, then what needs to be tested). My list includes the following:
Electronic Syndromic Surveillance
Procedures/Orders/Results Stuff
Password policy enhancements
SSL Configuration and Client Side certificates
Auditing/Logging
Emergency Access
Recording Disclosure
HIPAA de-identification
Sql-injection security (lots of under the hood changes in sql query code to support binding/placemakers)

If we were to freeze in a week or so, the only thing I see getting potentially done in time is Phyaura’s e-prescribing portal patch.

All the other stuff seems to be at least a month away or so(just my guess based on the previous pace of things).

Concerning testing, really only bugs in the new logging engine and sql-injection security stuff could be bad. However, these things have been around for some time and are testing well.

This is a community decision obviously, but why not just go for a full release soon with what we now have in the codebase?

-brady

drbowen wrote on Monday, September 13, 2010:

We have the OpenEMR 4.0 devtip up and running in our office since Friday morning.   So far all the basic functions that we were using before are working just fine.  The work flow change took some adjustment but has been accepted.

We are in the process of setting up the Laboratory results from LabCorp for live testing.

We are also setting up the patient reminders.

The front office clerks have been particularly positive about the improved work flow.

Sam Bowen, MD
http://oemr.org

penguin8r wrote on Tuesday, September 14, 2010:

This is exciting!  Good work everyone.
Dr. Bowen, any word on when the LabCorp results interface will be available to the general public?

mdsupport wrote on Tuesday, September 14, 2010:

We are looking forward to the CCHIT compliance.  However is it possible to have a target release date published for the base version so that we can start planning the conversion?  Also it will help if rather than delay the release for new functions / interfaces, the database changes are incorporated but the code is released in patches.

hrivera787 wrote on Tuesday, September 14, 2010:

Agreed!

>>We are looking forward to the CCHIT compliance. However is it possible to have a target release date published for the >>base version so that we can start planning the conversion? Also it will help if rather than delay the release for new functions / >>interfaces, the database changes are incorporated but the code is released in patches.

* New Features
* New Interface
* Database changes
Can come on the upcoming  versions.

I think the most important issue is:
* Fix Bugs
* Get certified

sraj49 wrote on Tuesday, September 14, 2010:

Dr.Bowen, I have a medium sized clinic with 20 doctors using version 4.0 from the dev tip and is working well. Like Brady had stated it is easy to fix bugs as there established working mechanisms. At least this way there will be number of people doing the road test and it is good for the products. I would love to put the unstable version to test. The way I do it I run two systems in parallel and mirror the database. This way the clinic keep running without interruption. Where can I access the unstable version as above.

Thanks for your understanding

Raj

allenluo wrote on Tuesday, November 30, 2010:

Is the code for the drug decision support and surescript e-Rx functionality at:

http://openemrsupport.com:10080/openemr-drugdb/interface/login/login_frame.php

posted anywhere? I couldn’t find it through the tracker or on the forums anywhere.

tmccormi wrote on Tuesday, November 30, 2010:

Nope.  It’s not released for 4.0 yet.  PhyAura is working on a solution.
-Tony