Proposal: ClearHealth, FreeMED and OpenEMR

synseer wrote on Tuesday, June 14, 2005:

Hello,
My name is Fred Trotter and I am the project manager of ClearHealth and FreeB. I am formally proposing a consolidation between the ClearHealth, OpenEMR and FreeMED projects.

This message is being cross posted on all the relevant forums. So far I have discussed this issue with the FreeMED BOD, and several OpenEMR community members. At this point, it is time to put the proposal to the community.
   
Why should there be a consolidation?
To avoid duplication of effort. Because we are all developing very similar EMR systems using the same fundamental technologies. Each of the three projects is separately generating incompatible code to meet exactly the same requirements. If the three projects combined their efforts we would have a better EMR and Medical Practice Management System in far less time than we might working apart.
   
What does consolidation mean in this context?
That is something that the community needs to come to an agreement on. I think this could mean anything from the complete refactoring of codebases, to friendly and structured exchange of code. I think the optimal solution would be a period of collaboration and communication, followed by a consolidation of code bases and the development of legacy support projects (or migration scripts) for the old code bases. But that is just my opinion, what does the community think?

We, as a collective community, have been spinning our wheels for a long time. Each community has strengths and weaknesses. Why can’t we combine strengths to eliminate weaknesses? First we need a candid assessment of what each project has and does not have. I do NOT mean this as hostile criticism, what I am trying to do is create an honest picture of what the real situation is, so that we as a community can figure out what to do next. I expect these criticisms to provoke strong feelings, and, hopefully, equally candid responses. I hope that the replies to this post will help us determine two things, where we are now, and given that status, where we should go. Feel free to disagree with my assessments, but to avoid a flame-war please try to back up your position with verifiable facts. At the beginning of your comments please introduce yourself, since you may not be known as well outside your community. I will cross posts relevant comments where possible. I believe the appropriate place for a central discussion is the new openhealth list, so that is where I will be talking most. I will leave out anything that I see as a positive or negative for all of the projects. This is intended to provoke discussion.

Here goes.

ClearHealth
ClearHealth is a young project funded by Uversa, Inc.  Uversa has hired several of the key players to work on ClearHealth. I want to specifically mention three. The first is  David Uhlman, who is well known in the OpenEMR community.  The second is myself, Fred Trotter. There is a LinuxMedNews interview with me that explains who I am and what I think about things. http://www.linuxmednews.com/1113401258/index_html

The third is Josh Eichorn, Josh and David are especially important because they are the primary architects of ClearHealth. Josh is well-known as the maintainer and author of phpDocumenter which is a standard within the PHP community. A look at Joshes website http://blog.joshuaeichorn.com/ to see more about his programming background.

As a result of the fact that Josh and David are first class architects, and David and I have a deep background in the current architecture of FreeMED and OpenEMR, I feel ClearHealth has the cleanest layout and most progressive core features of any of the three projects.

Specifically, we have an advanced Calendaring system. We also have FreeB2 which has some features that cannot be found in any other Medical Billing System, like claim revision control. FreeB2 is the centerpiece of the ClearHealth collaborative strategy, and there is already commitment from some non-PHP projects. Eventually this collaboration will generate a wealth of billing formats, which is the only reason to use a separate billing engine.   

Our architecture also has what we are referring to as EMR Extensions and Dynamic Reports. EMR Extensions are a method for extending the EMR without programing. Dynamic Reports allows you to create searchable and editable reports. So that you can both query and modify the data in the same system, again without programming.

FreeMED
FreeMED has a lot of features. It handles faxes and has a system for handling images. It is based on lots of trail and error over a long history. It has a small but loyal community. It has some valuable international relationships.  FreeMED has a nonprofit corporation that operates in FreeMEDs interest. It is also the oldest project, so it has had a long evolution.

While the system is modular, it is not OOP. The project manager, Jeff Buchbinder, is the only person who is familiar enough with the code to make major changes. Over time several people have tried to contribute to FreeMED, and been frustrated. As a result, FreeMED has been forked several times. FreeMED does have a second generation billing engine (REMITT) but adoption by other projects has stalled because of a patent cloud.

OpenEMR
A large and vibrant community. There are several companies that provide professional support. The code base is slightly more modern than FreeMED, and as a result changes are more possible and the culture of the project seems to encourage this.  As a result the project is moving forward.

The project seems headless. There are several versions of the code in parallel. While there is a lot of activity, there does not seem to be to much publicly available documentation. There is no discernible project manager, or definite direction.  OpenEMR is also supporting the original perl based FreeB. Which I am no longer maintaining. This makes the system very difficult to install and maintain, because it is not possible to take advantage of the improvements of Jeff Bucbinders REMITT or FreeB2. To be a viable project OpenEMR needs a supported billing system. The choice is either to merge with ClearHealth,  integrate with FreeB2 , sort out REMITTs patent issues, or start a billing system from scratch.  Given that most of the OpenEMR-only features could be implemented in ClearHealth without programing by EMR Extensions,  porting FreeB2 seems more and more wasteful.

There are also issues with the main codebase. The PHP coding practices which are based in PHP 3. This includes the evil register globals, which makes OpenEMR almost impossible to secure.  The amount of code rewrite that it will take to make the codebase modern and secure is considerable. Given that these things are already working in ClearHealth, is this worth working on?

Although I loath to put forward any specific plan, I will ask a pointed question. Why don’t we move toward using the clean architecture of ClearHealth, combined with the vibrant community of OpenEMR, and refactored feature set of FreeMED? The gap between OpenEMR and ClearHealth could be addressed using EMR Extensions. Some of the major features of FreeMED would need porting, but with an open invitation to Jeff Buchbinder to take a role as a developer on the combined project, those things could happen very quickly.

I am quite aware of that there are investments in current brands, companies and project mechanisms. I am not proposing any organizational merger, the various organizations should  continue addressing their own priorities. Many opportunities are being missed developing in parallel. Lets work together.

Regards,
Fred Trotter

sunsetsystems wrote on Tuesday, June 14, 2005:

Fred,

It might help if you make a (much!) more specific request.  The notion of working together sounds great, but I can’t imagine any forward movement with your proposal as it appears here.

Also where is this “new openhealth list”?  I suppose I should know, but I’ve been busy…

A couple of related comments and questions:

(1) How many "production" users does ClearHealth have?  Who are they?  Have any of them successfully completed a full cycle of billing, including receipt of payments?

(2) While OpenEMR has undergone some change in leadership, it is "headless" only in the sense that there is no project dictator.  We are liking it that way.  Some casual browsing of these forums will show that we have accomplished a great deal in the past three months, and more major improvements are happening as we speak.  Most of these are at the same time addressing the issues with crufty code.

(3) We understand the limitations of the the old FreeB and are looking forward to taking advantage of FreeB2.  When might it be released as a standalone project?  Indeed, I see that as an important step in the nurturing of cooperation between the projects.

(4) Isn’t ClearHealth, while technically open source, primarily a commercial venture?  You guys have expressed an intent to retain tight control over its development process, and to profit directly from its success.  By contrast, the OpenEMR developers have recently identified as part of their mission to reject activities that favor any commercial venture over another, or that might favor the interests of a vendor over those of its users.  Any collaborative activity would need to respect these core values, which I’m pretty sure means maintaining the identity and independence of the OpenEMR project.

Thank you in advance for your thoughtful consideration of these comments and questions.

– Rod <rod at sunsetsystems dot com>

synseer wrote on Tuesday, June 14, 2005:

Rod,
       The openhealth list can be found here
http://groups.yahoo.com/group/openhealth/
I would also like to point out the recent post from MSgt Cook,
http://groups.yahoo.com/group/openhealth/message/79
He has good questions for all of us, which would be profitable to answer, even in the absence of a consolidation.

I am quite aware that my proposal is nebulous, and it is so intentionally. I did not want to make a specfic proposal, since I have no idea about what everyones priorities are, instead I am asking something like "What proposal would be accepted?". Your questions and comments in this regard are really helpful, because the represent the first step in that direction.

(1) Currently we have three production sites. I do not mind discussing them with you offline, but imagine that they might be uncomfortable discussing them in a public forum. Currently we are running our first round of live billing at two of the three.

(2) Your argument essentially says that you might prefer not having a dictator of any kind, even a benevolent one. There are lots of good projects that are run from coucils (Apache) and others from using the benevolent dictator model (Linux). The end functioning of these type of organizations are very similar, because a good project manager treats the community members as a council anyways. I would love for ClearHealth to have a council, however it would be impossible for us to determine, at this stage, who would be good coucil members and who would not.

(3) FreeB2 will be released standalone sometime this week (assuming there is no upsets) everybody has been clamouring for this, and we are hurrying…

(4) You said…

…mission to reject activities that favor any commercial venture over another, or that might favor the interests of a vendor over those of its users… Any collaborative activity would need to respect these core values, which I’m pretty sure means maintaining the identity and independence of the OpenEMR project.

I agree 100%. First there is no reason AT ALL that the OpenEMR project needs to go away. This is a question of practical collaboration and codebase, not organizational structure. However, in any case, the question regarding commercial interests is very valid, and make no mistake Uversa is in this to make money. However, the interests of Uversa is to have an excellent communtiy-based project. We are still hiring out our webdesign work, but even now if you type clear-health.com and clear-health.org you go to very different places. This is intended to concretely indicate that the ClearHealth project is seperate and distinct from ClearHealth AAdvantage which is Uversas product version. Recently, we have seen Redhat move more and more towards a community based effort with Fedora. Uversa is trying to do exactly the same thing, but there is alot of work to be done to set up the Wiki/Forum/Blog/whatever and to invest heavily in those resources that build and sustain community (like excellent publically available documentation). Your goal is to make certain that vendors do not take advantage of users and one commercial interest does not outway another. We are releasing all of our code under the GPL and all of our docs under Creative Commons. So at the face of it, we are taking the steps to keep ourselves honest in that regard.

As for the issue of "close control of the codebase". Well this proposal is part of us intentionally loosing that some. I say some because we will always maintain very high quality control standards. Our intent is not to horde development, rather it is to protect its integrity.

Please dont read my proposal as "Stop what you are doing and put me in charge of your efforts" rather it is saying "How can we work together". What objective steps can Uversa take to demonstrate that the projects health comes before profit mongering? Because we do need to make a profit, but we are not going to scuttle the community to do it.

-FT 

sunsetsystems wrote on Tuesday, June 14, 2005:

Fred, thanks for the response.  It is very encouraging to hear that you are committed to a prompt FreeB2 release, and I look forward to checking it out.  This will surely lead to interesting discussions in various areas.

It’s also nice to hear that you guys are open to loosening control of the ClearHealth code base.  I encourage you to do this to a greater degree than you are comfortable with.  :slight_smile:

– Rod <rod at sunsetsystems dot com>

synseer wrote on Tuesday, June 14, 2005:

Rod,
         Well I imagine that some of my previous posts make me sound like a control freak with regards to a codebase. Which is not unjustified. I really really want an excellent project, and I have been very frustrated by the level of code quality that I have seen so far. Although I am also to blame for writing bad code as anyone who is using FreeB1 can tell.
        I do think it is time to focus on code quality and sound software engineering as a community. But please do not interpret this as a draconian position.
       I can see that releasing FreeB would be a good first step towards working together and possibly be a first step along the road to a greater consolidation. We will do that ASAP.
       How else can we practically prove ourselves to the OpenEMR community? What control should I become comfortable giving up?  :slight_smile:

Thanks,
Fred Trotter

drbowen wrote on Tuesday, June 14, 2005:

Dear Fred Trotter,

You have a lot of good ideas and express yourself very clearly.  We are all interested in solid object oriented code.  The current developers of OpenEMR are untangling the code that they inherited by joining this project.  It is a bit unfair to imply they are responsible for code that they inherited from someone else.

Much of the code they are untangling passed through your hands  while working on FreeB 1.0 and David Uhlman while at Pennington Firm.

I think the mood of the OpenEMR community is that we believe in judging deeds, not words.

synseer wrote on Tuesday, June 14, 2005:

I did not mean to imply that anyone working on the project had written poor code besides myself. To be clear, this is not at all what I think. In fact I think that OpenEMR was very advanced for its time, but that architectures from that time suffer because they were targeted at PHP 3.

I also take full responsibility for the tangle that is FreeB1.

As far as deeds and words go, I would much prefer to prove myself with deeds. The point of the proposal is to discover what deeds are important to your community. Several people have suggested releasing FreeB standalone, so we will do that ASAP. What else would the community like to see?

Fred Trotter

sunsetsystems wrote on Tuesday, June 14, 2005:

Well with FreeB2 imminent, I’d like to see some discussion about accounting.  OpenEMR is rapidly becoming tied more and more to SQL-Ledger for such things as A/R, EOB entry, patient statements, collection letters, allocation of revenues, and related reporting.

What have you guys done or are planning in this area?  It it orthogonal to SQL-Ledger, or might it be integrated with it?

– Rod <rod at sunsetsystems dot com>

drbowen wrote on Wednesday, June 15, 2005:

In response to Rod Roark:

In medical practices, the AR management is much more complex than an average business.  I don’t think SQL-Ledger will ever be allowed by the SQL-Ledger developers to grow in this direction.  As such it is very necessary to have a medical practice management program that has a different function than that the general accounting of SQL-Ledger.

Medical practices need both types of programs - AR management and general accounting.  I think of the ideal solution as objects that perform separate functions, electronic health record, contact management, laboratory interface, practice management (AR management), payroll/time keeping and general accounting (tax accounting).

FreeB 2 is orthogonal and intentionally so.  Its purpose is different in that it is aiming to be practice management (AR management) not general accounting.  Currently there are some nascent general accounting programs that have similar architectures to OpenEMR, ClearHealth, FreeB 2, but none of them come close to the functionality and stability of SQL-Ledger.

SQL-Ledger is a bridge to get us to the end product of a practice management system that contains all of the above.  It introduces a complexity of installation that is much harder to deal with but the sophistication os SQL-Ledger is worht the effort at this time.  As time goes by some of the PHP-MySQL accounting systems are likely to catch up and will become better solutions.

In my current practice I have an old MSDOS-based practice mangement system (the original version is from 1975) that is wizardly fast, efficient, and impossible to teach new tricks.  It still cannot print on a HCFA 1500 with a laser printer for instance.  I put up with it because it does its job of practice management so well.

At the end of the day we transfer the deposit to QuickBooks for our general accounting.  This is the way most of the practicing physicians are getting by.  It would not be unusual or difficult to post balances at the end of the accounting day from FreeB 2 to SQL-Ledger.  Ultimately there will be a PHP-MySQL accounting system that will take over this funciton.

__________________________________________________

In response to Privacy Geek:

We appreciate the effort you are puttng into debugging OpenEMR.

First a question, which version of OpenEMR are you working on?

We are trying to get rid of the postnuke calendering for the same reasons you are trying to debug this.  Maybe you use your time to help get rid of the postnuke calender instead of fixing it?

We are working on unifying the code in OpenEMR.  We have adopted several principles that all the new code should be based on plus we are trying to replace the older code with new object oriented code.

Formscript.pl was written by markleeds.

Sam Bowen, MD

synseer wrote on Wednesday, June 15, 2005:

In response to the AR discussion-

I agree with Dr Bowens comments. Medical Accounts Recievable is a different beast then just Accounts recievable. The other problem is the bridge. We are trying to keep everything natively in PHP. The overhead of maintaining a php/perl app is too large, (one of the reasons that FreeB2 is written in php). Perl is great for rapid development and is capable of doing profound capabilties in not-very-much code. It is also extremely difficult to maintain.

For these reasons we are attempting to make our AR system entirely in PHP. We are not starting from scratch, Uversa has done accounting system work in other applications, but I am still working on getting the system to be Medical Specific.

Some of the specific features that are needed in the medical arena that are different in standard accounting have more to do with workflow than accounting practices. For instance, how much time does it take to reconcile and Expliantion of Benifit (EOB) statement from an insurance company? The EOB line items need to map to encounters within the EMR. I wrote the EOB entry wizard for FreeMED but I think the system that ClearHealth uses now is much cleaner. The other area is aging reports. This is related to the problem unique to Medical that the people that you bill often dont pay at all, dont pay enough, or pay intentionally late.

The AR system we are developing is intended to address these issues, as well as enable practices to run things thier own way. i.e. functions for daily closers vs. weekly closers.

While it is not intended to be intergrated the way FreeB2 is, there is no reason that OpenEMR cannot also borrow ClearHealths AR system.

-Fred Trotter

synseer wrote on Wednesday, June 15, 2005:

regarding privacy geeks questions.

(2) CVS - No ClearHealth uses subversion. Yes we will be sharing it, and no it is not public yet. This is one of the infrastructure pieces that we are still working on.

(6) I am not sure what that script does, but I am assuming that it automatically creates forms. We have a system to do that, but it is entirely PHP, and handled throught the interface. It might be possible to take current forms in OpenEMR and autogenerate the equivilant in ClearHealth. Even if it is done by hand it would be very fast.

openemr wrote on Wednesday, June 15, 2005:

Hi All,
      sorry about the incorrect attribution on formscript.pl first.

In answer to some questions

1. the version(s) of OpenEMR I am debugging is 2.72+,(CVS seems to be lacking some components as of late on a fresh checkout).

2.I will be using OpenEMR to provision a City of Oakland Agency(we issue Medical Cannabis IDs on a Windows based system at present) for EMR systems.

3. I have been implementing a new card production system as a backend on OpenEMR, I HAD planned on using OpenEMR as a frontend for the Records Gathering process.

4. The forms I have been working on for gathering stats on usage,complaints,frequency will be available soon.

5. I had been on the verge of delivery of a test system prior to this calendar bug…

6. I had used SQL-Ledger for years(personal pref). My needs for an accounting system except for POS were minimal

7. as soon as the code base is somewhat stable I had planned on implementing DB "translucency"(We already encrypt the patient/MD DB  disk but this will involve the principles laid out in Peter Wayners "Translucent Databases")
applied to any identifying information in our Patient and MD DBs.

8. My background is applied security and cryptography currently reason for #7 above.

9. I guess I will unpack clearhealth today and see what mods
are needed to get my back end implemented.(Is everybody sure this is the direction the code tree needs to go?)

10. My main concerns are that forms created under OpenEMR will work without major mods in clearhealth.

11. a unified code base would be a wonderous thing given the various coding styles/design patterns I see in OpenEMR
.
12. Subversion sounds OK, how soon?

13. What about the infrastructure that is accreting around OpenEMR… the WIKI etc …

14. What does the rest of the OpenEMR userbase think?
(I cant be the ONLY vocal user besides the developers :slight_smile:
     an OpenEMR user…

synseer wrote on Wednesday, June 15, 2005:

Recently Michael Rowley sent me a detailed descrition of his user experience with OpenEMR. His implied question is "how would my experience with ClearHealth be any different" which is a reasonable question. However, I know that the OpenEMR community has addresses some of the problems that he had at that time. I am posting his letter here in its entirety. Can someone tell me exactly what the current status is on the issues he has had. I do not want to waste anyones time analyzing issues in an old codebase. I hope this will be usefull to the OpenEMR community irrespective of the consolidation proposal.

His Letter>

    My wife and I recently opened a practice together.  Our opening date was July 19th, 2004.  When we were setting up the practice, we made several decisions about how we were going to practice.  One was that we were going to have an electronic medical record in place, as we had both used electronic records in our residency, and could see the advantages of computerized medical records.  We choose to use Mac OS X machines as our workstations, and Gentoo Linux as our servers.  One of my goals when opening the practice was to use as much open source softare in the business as we could.  I investigated several options, and came to OpenEMR as the a viable solution based on maturity and support.  We had OpenEMR installed by Pennfirm in June, 2004 to give us some time to use the software and get used to it.  Since that time, we have continued to use OpenEMR for about six months now, and have become familiar with it’s strenghts and weaknesses.

OpenEMR’s strenghts include:
1)Cost: it is open source software, so we paid the cost of installation.
2)Support: it is supported by Pennfirm, which is a company which works with several open source projects to support users for pay. 
3)Portability: as this is web based software, we could access it from home without much difficulty.  For security the emr server is behind a firewall, so we access it through port forarding via ssh.
4)Billing: The software uses freeb, a second open source project to develop the billing documents.
5)Expandability: as open source software, and being written in PHP, I can fairly easily modify the software do do what I want, or have it modified by a contractor.

    To deal with the benefits of OpenEMR systematically.  The cost of installation included setting up the server with openEMR, mysql, and freeb, not the actual operating system install.  We paid Pennfirm $2500 for this installation, and then support for 90 days.  This is about 1/10th what we would have paid for a proprietary closed source package.  I choose gentoo linux for our operating system, installed apache, php, and mysql (which was a breeze with gentoo, actually).  Pennfirm then came in and  set up OpenEMR, freeb, and performed training with my staff and myself.  They also customized 3 forms for us.
    The first limitation of OpenEMR that we soon found was that it did not interface with any standardized accounting software.  It is set up to export the financial data as an OFX (Open Financial Exchange) file, but the accounting software that we found would only use OFX to reconcile an account, and expected it to be a file that would come from you bank, listing actual deposits and debits.  Initially I tried to set the system up to do our accounting with MYOB AccountEdge software, but had difficulty setting up the automatic transfer of the billing information.  I then tried QuickBooks, and GNUCash, with the same difficutly.  By August we realised that we had a significant problem.  We could not track our Accounts Recievable, and I was much too busy to try to find a solution on my own.
    I contacted Pennfirm to assist us with the problem, and contracted them to provide an accounting solution for our practice.  The necessities were to have an accounting package that would perform several basic tasks:
1)Track our AR
2)Transfer billing information directly from OpenEMR
3)Allow entering data from the EOB’s.
We contracted in the end of August for a solution that was initially to to take 6 weeks, and be completed by the middle of October. 
    Pennfirm initially choose a project avaliable from souceforge, ezybiz.  This initial attempt did not come out well, and in October Pennfirm and I decided that ezybiz was not a completable project as the underlying project was not functional.  At that time we choose a second project, SQL-Ledger to attempt our integrations.  SQL-Ledger is a full fledged accounting package in its own right, with a large support community and user base.  The initial completion date for the project was set as December 17th, 2004.  The project was installed on my server by January 5th, 2005, and we began to test the software.  The initial testing on the package modifications to SQL-Ledger  were sub optimal, and it became rapidly apparent that the package was not going to function in a reasonable fashion.  The reasons for this are as follows:
1)Errors in calculations.  These should be easily repairable.
2)Difficulty of entering data: this is more complex, as the EOB’s could be entered but only one line item at a time, making the completion of an EOB a significant number of steps.
Due to these, we did not reach a point that we could successfully catch up our AR or produce a bill for our patients.  At that point we contracted our billing to a company that we could export our data to, and they would manage our AR, and billing.  To be fair, OpenEMR is not advertised with the functionality to track AR, and our inability to do so was due mostly to my inexperience. 
    The limitations of OpenEMR are a bit more subtle.  Some of them can be easily worked around. Some of these limitations are significant, and pervasive to the design of OpenEMR.
1)Open EMR has only two security settings, authorized, and unauthorized. Authorized users can do anything, and are listed on the calendar.  They have the ability to access the practice settings, and database settings without limitations.  Unauthorized users all have to have any action with the exception of appointments approved by an authorized users.  These authorizations all appear in the bottom in the scheduling screen after logging in.  These unfortunately are not just for the logged in provider, but lists all providers.  The name of the provider is listed on my system, but I added that functionality and submitted it back to OpenEMR.org for addition into the source.
2)There is no way to currently track open encounters, or to finalize encoutners. This means that all encoutners are only accessible through the daily calendar. Billing is submitted as soon as it is entered, and if an encoutner is not completed, there is no reminder that it has not been finished.
3)OpenEMR is not thread safe.  This is by far the most fatal flaw of OpenEMR. What this means is that when an patient account is open a browser window(1), if a new window(2) is opened, and you go to a different patient account, if you go back to the first window and save any data, it will be saved to the patient account or encounter open in window(2).  This does not occur if you are on a different machine, or if you use a different browser.  I have been told that this may be a limitation of PHP, but I have not verified that yet.
4)No Login tracking.  If you do not log out at the end of a session, the session will time out, but the screen will not reload to the log in screen.  Also, if you are entering a long note, and go beyond the time allotted for the session, it will expire, and will go to the log in screen when you submit the note.  This results in the loss of the note.
5)There is no easy way to set the billing date on submitted billable codes.  For example, if you see a patient on Friday, but do not enter your billing till Monday, the billing will be submitted with the date of service of Monday.  Also, if you add a form to an encoutner, then the date of the encoutner will be changed to the date the last addition to the chart was made.

synseer wrote on Wednesday, June 15, 2005:

Security Geek.

Most of your questions probably merit their own forum thread since they do not bear on the consolidation proposal directly. Your bugs from OpenEMR will all be replaced by new and different bugs if you move to ClearHealth :slight_smile:

10. My main concerns are that forms created under OpenEMR will work without major mods in clearhealth.

To be more specific about this involves a long description of how EMR Extensions work in ClearHealth. Essentially given a standard webform, you replace the form elements with Smarty Tags of exactly the same type. These tags are smart enough that they will automatically create the DB table needed to track your data. Then you associate that DB table either with a patient record or an encounter record. So if you wanted to track one time data (Perhaps a useful ID) then you associate it with a  patient. If you want to record something about interactions with a patient then you associate the form with your encounter. That means that as long as you have a working web form it will be easy to move over.

12. Subversion sounds OK, how soon?
We are working to mirror our internal subversion server to a publically available one. This should happen within the next 2-3 weeks.

-Fred Trotter

sunsetsystems wrote on Wednesday, June 15, 2005:

I’ve got a lot going on this week and next, but I feel obliged to respond to this one as I have in recent months encountered and addressed most of these same issues:

(1) Security has been greatly improved with integration of phpGACL into OpenEMR.  This implementation is only partly finished, but the basic foundation is in place and some important areas of the code are now done.

(2) This problem is fixed by the recent addition of a report to cross-reference appointments with encounters, so appointments with missing or incomplete encounters are easily identified.

(3) is not a limitation of PHP, it was a plain old bug and a very dangersous one.  I fixed it.

(4) Still not addressed, but you can adjust the time limit on a session as a configuration parameter.

(5) These and many other deficiencies related to billing, EOB entry and encounters have been resolved.  See the 2.7.2 release announcement which contains a bit more information.

– Rod <rod at sunsetsystems dot com>

openemr wrote on Wednesday, June 15, 2005:

Hi Fred,
Hmm I would have maintained dual development paths had I been able to find a developers archive for clearhealth,
the requesting city agency has been extremely patient in waiting for delivery though all of the debugging this has taken due to a shifting code base…

smarty templates are probably not what I am looking for… I am more looking for APIs to hack my existing base of openemr centric code onto.

My sounds of desperation over having current sources is  the same one that is hitting me for this migration( I need to have eyes in the back of my head to predict where the development base is going :frowning:

I will unpack the last public posting of clearhealth and look deep within… I really do want my agencys project living on the
living development path. If we are to leave OpenEMR behind, I am for it as long as I can find adequate information on clearhealths internal API(I am dependent on a number of classes and includes from the rest of openemr for my backend.)(that PN Calendar BUG is really irritating).

     an OpenEMR user(soon to be clearhealth??)

sunsetsystems wrote on Wednesday, June 15, 2005:

Regarding (1), what is missing from CVS?  If this is truly a problem it may be my fault (I’ve added and removed a lot of stuff recently).

Regarding the calendar loop: try removing all of your calendar events (table openemr_postcalendar_events, but of course back it up first).  You probably have some malformed event that is confusing the code, in which case identifying the problem event will make debugging a lot easier.

– Rod <rod at sunsetsystems dot com>

openemr wrote on Wednesday, June 15, 2005:

Hi Rod,
sf.net keeps logging me out this morning…
(it doesnt seem to like tor/privoxy etc type tools)

no events are in the calendar yet  this is a fresh cvs install

I pull from CVS into a fresh directory run

setup.sh(precreating the database) and find it populated by only 14 tables,
I then drop the DB and reinstate it via source openemr/sql/database.sql.

Insert the admin user into users and login.

I tried installing 2.72 (it gets the table creation correct at least but exhibits the same Pn loop(the calendar is not used yet this is a fresh install

Mysql 4.1.1(any info on moving to 5.06?)

OpenBSD-current.

php 4.3.11

Xdebug 1.3.6?(current turned off caused redirection exceeded messages)

openemr wrote on Wednesday, June 15, 2005:

Uh Rod… we really should move the to the calendar doesnt show thread(I DONT know how to do this can you?)

    An OpenEMR User

sunsetsystems wrote on Wednesday, June 15, 2005:

No but I posted a followup there.

– Rod <rod at sunsetsystems dot com>