I am making the changes that allows (a subset of the) BBCodes in the CAMOS reports. Here is what I am trying to accomplish:
1) You put the BBCodes in the actual report item. When you do the "Submit All Content" routine, it will pull the form, with BBCodes and all, into the Encounter. So the actual item that is saved includes the BBCodes.
2) The display function calls a routine that replaces the BBCodes with HTML, so what is actually displayed in the Encounter is the "final product."
3) When you do one of the print functions, it will process the BBCodes as needed (either the HTML or some equivalent PDF command).
That is my intention. At this time, I have the function working so that most of the BBCodes I allow are being translated into HTML for the Encounter display. Once I have that part working, I'm going to go on to fix the HTML based printouts. At that point, I'll need some help - I've never really attempted to product PDF reports, so I'm not sure what'll be needed.
CAVEAT NOTICE: I am new to OpenEMR development. I have not (yet) made a git account, etc. I plan on doing that soon, and attempting to incorporate my code into that so I can submit it for testing and such. Any help/suggestions/etc would be greatly appreciated.
There are things like the "clone" process that I have not yet even thought about taking into consideration. I figured that I'd cross that bridge once I had the printed reports done. But this is where y'all come into play - because you'll know of the other things that I'll have to take into consideration, and can give me the guidance I might need to do this right.
Thanks muchly,
Lee Crites
lee@tbfed.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am curious of why people are interested in leaving Soapware. I looked at their web site and for me, the number one problem is that it requires a Windows server (We eradicated Windows from our office and are now a hybrid Linux/OSX office - and we couldn't be happier).
-Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After a couple of false starts, I have something working. It's not complete, by any stretch of the imagination. I can get it working at one level, but find that another isn't quite right, so I move things around a bit - I just haven't yet figured out the best places to call the BBCodes parsing function.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's a good idea, interpreting BBCodes. It would make sense to leave the BBCodes intact in the database and only interpret them for display. In that case, you could call the interpreter in notegen.php and report.php. You could put your interpreter in a separate file or in content_parser.php where there are similar functions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) Proprietary database that we have no real access to.
2) Not only do you have to have windoze, you have to have the version they run on. Oh, and you have to upgrade the MSSQL server if you have any real number of records, which is also tied to the version of windoze you have.
3) To upgrade, we'd have to buy new hardware to run the new windoze OS, which means we'd also have to buy the new MSSQL server as well. That's a hefty chunk of change.
4) We were going to have to pay to upgrade (they stopped supporting our current version).
5) We were going to have to pay for training to use the new version.
6) We were going to have to go through the steep learning curve.
7) None of the folks we talked to who had done so were happy with it.
8) Some of the folks we talked to said not everything in their old database made it to the new one intact - so the upgrade wasn't really 100%.
We thought: if we are going to have to buy new hardware, new software, new training, and go through a new learning curve - all forced upon us because the software vendor decided to cease supporting us, then why reward them for that?
OpenEMR has some things that are not as nice as SOAPware - things like keystroke macros. But, going back to my previous list:
1) We have full access to the database, and what is in there. I have written scripts to migrate the bulk of the SOAPware data, and what I couldn't port/migrate, I will build a PDF file that contains everything, and we'll just add it to the records. It's not pretty, but it'll work.
2&3) We have a linux server that runs OpenEMR beautifully. Plus, we stumbled on EHRlive, and are having them host it for us - at a cheaper rate than SOAPware was going to charge us for yearly maintenance.
4) OpenEMR is free, as are all upgrades and updates. Free is a darn sight better than the $2k invoice SOAPware sent us.
5) EHRlive sent us a training DVD. So training wasn't actually free, but it was cheap enough that it wasn't an issue.
6) The learning curve is the learning curve - this one was a wash.
7) We might not be 100% happy with OpenEMR, but we were not 100% happy with SOAPware, either. I am a software developer, so I'm already looking into what I can do to help make some of the changes we'd like to see happen. Eventually, we'll be as happy with this as we ever could have been with SW.
8) I never got the details about what did/did not migrate with SW, but I know what will/will not for us. I will pull everything pertinent across in some format.
Bottom line: We had to change software. Why reward the company that perpetrated that need by paying them (fairly large amounts of money)? We have to learn a new system. We have to get used to doing things a different way. So why not go with one that seems more stable, and one that we have more control over?
I'm not telling other folks they have to leave SOAPware. We did (and are still in the process of doing so); we'll be happy with the change. If others need to make the same move, I'll be more than happy to toss the scripts and such I used to pull it off their way, as is.
Lee
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I contemplated putting all of my changes into content_parser.php - that is really pretty much the most logical place for it. But, to be completely honest, this is my first attempt at making changes to OpenEMR software, and I didn't want to fritz around with the actual code. I figured the less I changed the actual code, the better it would be (for now).
I plan on using OpenEMR as part of the suite of offerings my consulting company will provide to small doctor's offices and clinics. This isn't a one-shot deal for me. That being the case, I'll probably do more software development as time goes on - at least I'll offer to do so. Accepting my contributions will be up to y'all.
So I figured that I'd attempt to encapsulate my changes into a single file so it would be easier for one of the "real" contributors to look at it and add it into the real code. Then when that time comes, and we come to an accord about future development, then I could jump into the foray.
I've been in the computer industry since 1976. I know what it's like to have some newbie interloper show up and start hacking and slashing about. I'm not about to do that to y'all. At least not yet, anyway… :-)
Lee
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's only several developers whom know much about CAMOS development; I'm guessing that by this point you are now one of them… Looking forward to seeing your code.
-brady
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for sharing your views on SA. I have heard about SA and was just curious. I agree with you on the Windows issue. There is no way I will ever allow anything Windows in our office again. We drank that Kool Aid for far too long. Since getting rid of Windows, I no longer have to spend my time fixing things. I am like the Maytag repairman for IT support in our office now. We run Linux/OSX and things just work.
-Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I went through the GIT instructions without success. No matter what I try to do, when I do the ssh git@github.com (and every other command from that point on), I get the "Permission denied (publickey)" error. I have followed the github troubleshooting guide; I have searched the internet for help; I have uninstalled and reinstalled ssh; I have deleted and rebuilt my key files more than a dozen times. Nada. So until I can do the GIT thing, I'm pretty much left to the "old fashioned" methods.
I know there is something painfully simple that is wacked, but I'm not sure what it is. Like I said, I uninstalled and reinstalled ssh, so it should be clean.
Lee
Just FYI:
* Ubuntu 10.10, gnome
* ssh -V: OpenSSH_5.5p1 Debian-4ubuntu5, OpenSSL 0.9.8o 01 Jun 2010
* results from ssh-keygen, RSA option:
lee@vostro1510
/home/lee/.ssh
:lee@vostro1510:~/.ssh$ ssh-keygen -t rsa -C "lee@TBFed.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/lee/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/lee/.ssh/id_rsa.
Your public key has been saved in /home/lee/.ssh/id_rsa.pub.
The key fingerprint is:
84:92:48:50:71:96:55:29:a5:5d:50:81:cd:0f:94:07 lee@TBFed.com
* results of ssh-keygen, DSA option:
lee@vostro1510
/home/lee/.ssh
:lee@vostro1510:~/.ssh$ ssh-keygen -t dsa -C "lee@TBFed.com"
Generating public/private dsa key pair.
Enter file in which to save the key (/home/lee/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/lee/.ssh/id_dsa.
Your public key has been saved in /home/lee/.ssh/id_dsa.pub.
The key fingerprint is:
43:72:8d:43:20:d4:58:2b:33:2f:50:d3:45:d1:56:cf lee@TBFed.com
* results of ssh -v git@github.com:
:lee@vostro1510:~/.ssh$ ssh -v git@github.com
OpenSSH_5.5p1 Debian-4ubuntu5, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com port 22.
debug1: Connection established.
debug1: identity file /home/lee/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/lee/.ssh/id_rsa-cert type -1
debug1: identity file /home/lee/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: identity file /home/lee/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5github2
debug1: match: OpenSSH_5.1p1 Debian-5github2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /home/lee/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/lee/.ssh/id_dsa
debug1: Authentications that can continue: publickey
debug1: Offering public key: /home/lee/.ssh/id_rsa
debug1: Remote: Forced command: gerve tbfed
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Server accepts key: pkalg ssh-rsa blen 279
Agent admitted failure to sign using the key.
debug1: No more authentication methods to try.
Permission denied (publickey).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, it's been nearly a year since my last message. A couple of client issues caused me to have to retrench and rebuild. I'm now "back among the living," so to speak, and will probably start looking into this again.
- Lee
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Y'all;
I am making the changes that allows (a subset of the) BBCodes in the CAMOS reports. Here is what I am trying to accomplish:
1) You put the BBCodes in the actual report item. When you do the "Submit All Content" routine, it will pull the form, with BBCodes and all, into the Encounter. So the actual item that is saved includes the BBCodes.
2) The display function calls a routine that replaces the BBCodes with HTML, so what is actually displayed in the Encounter is the "final product."
3) When you do one of the print functions, it will process the BBCodes as needed (either the HTML or some equivalent PDF command).
That is my intention. At this time, I have the function working so that most of the BBCodes I allow are being translated into HTML for the Encounter display. Once I have that part working, I'm going to go on to fix the HTML based printouts. At that point, I'll need some help - I've never really attempted to product PDF reports, so I'm not sure what'll be needed.
CAVEAT NOTICE: I am new to OpenEMR development. I have not (yet) made a git account, etc. I plan on doing that soon, and attempting to incorporate my code into that so I can submit it for testing and such. Any help/suggestions/etc would be greatly appreciated.
There are things like the "clone" process that I have not yet even thought about taking into consideration. I figured that I'd cross that bridge once I had the printed reports done. But this is where y'all come into play - because you'll know of the other things that I'll have to take into consideration, and can give me the guidance I might need to do this right.
Thanks muchly,
Lee Crites
lee@tbfed.com
I am curious of why people are interested in leaving Soapware. I looked at their web site and for me, the number one problem is that it requires a Windows server (We eradicated Windows from our office and are now a hybrid Linux/OSX office - and we couldn't be happier).
-Mike
BBCodes in CAMOS update:
After a couple of false starts, I have something working. It's not complete, by any stretch of the imagination. I can get it working at one level, but find that another isn't quite right, so I move things around a bit - I just haven't yet figured out the best places to call the BBCodes parsing function.
That's a good idea, interpreting BBCodes. It would make sense to leave the BBCodes intact in the database and only interpret them for display. In that case, you could call the interpreter in notegen.php and report.php. You could put your interpreter in a separate file or in content_parser.php where there are similar functions.
mike-h30: Why leave SOAPware?
1) Proprietary database that we have no real access to.
2) Not only do you have to have windoze, you have to have the version they run on. Oh, and you have to upgrade the MSSQL server if you have any real number of records, which is also tied to the version of windoze you have.
3) To upgrade, we'd have to buy new hardware to run the new windoze OS, which means we'd also have to buy the new MSSQL server as well. That's a hefty chunk of change.
4) We were going to have to pay to upgrade (they stopped supporting our current version).
5) We were going to have to pay for training to use the new version.
6) We were going to have to go through the steep learning curve.
7) None of the folks we talked to who had done so were happy with it.
8) Some of the folks we talked to said not everything in their old database made it to the new one intact - so the upgrade wasn't really 100%.
We thought: if we are going to have to buy new hardware, new software, new training, and go through a new learning curve - all forced upon us because the software vendor decided to cease supporting us, then why reward them for that?
OpenEMR has some things that are not as nice as SOAPware - things like keystroke macros. But, going back to my previous list:
1) We have full access to the database, and what is in there. I have written scripts to migrate the bulk of the SOAPware data, and what I couldn't port/migrate, I will build a PDF file that contains everything, and we'll just add it to the records. It's not pretty, but it'll work.
2&3) We have a linux server that runs OpenEMR beautifully. Plus, we stumbled on EHRlive, and are having them host it for us - at a cheaper rate than SOAPware was going to charge us for yearly maintenance.
4) OpenEMR is free, as are all upgrades and updates. Free is a darn sight better than the $2k invoice SOAPware sent us.
5) EHRlive sent us a training DVD. So training wasn't actually free, but it was cheap enough that it wasn't an issue.
6) The learning curve is the learning curve - this one was a wash.
7) We might not be 100% happy with OpenEMR, but we were not 100% happy with SOAPware, either. I am a software developer, so I'm already looking into what I can do to help make some of the changes we'd like to see happen. Eventually, we'll be as happy with this as we ever could have been with SW.
8) I never got the details about what did/did not migrate with SW, but I know what will/will not for us. I will pull everything pertinent across in some format.
Bottom line: We had to change software. Why reward the company that perpetrated that need by paying them (fairly large amounts of money)? We have to learn a new system. We have to get used to doing things a different way. So why not go with one that seems more stable, and one that we have more control over?
I'm not telling other folks they have to leave SOAPware. We did (and are still in the process of doing so); we'll be happy with the change. If others need to make the same move, I'll be more than happy to toss the scripts and such I used to pull it off their way, as is.
Lee
markleeds:
I contemplated putting all of my changes into content_parser.php - that is really pretty much the most logical place for it. But, to be completely honest, this is my first attempt at making changes to OpenEMR software, and I didn't want to fritz around with the actual code. I figured the less I changed the actual code, the better it would be (for now).
I plan on using OpenEMR as part of the suite of offerings my consulting company will provide to small doctor's offices and clinics. This isn't a one-shot deal for me. That being the case, I'll probably do more software development as time goes on - at least I'll offer to do so. Accepting my contributions will be up to y'all.
So I figured that I'd attempt to encapsulate my changes into a single file so it would be easier for one of the "real" contributors to look at it and add it into the real code. Then when that time comes, and we come to an accord about future development, then I could jump into the foray.
I've been in the computer industry since 1976. I know what it's like to have some newbie interloper show up and start hacking and slashing about. I'm not about to do that to y'all. At least not yet, anyway… :-)
Lee
Lee,
It would be great if you'd post your SOAPware conversion scripts on the wiki:
http://www.openmedsoftware.org/wiki/OpenEMR_Database_Conversion_Tools
Also feel free to hack/slash away; the best way for us to test/review your code is vua git/github which is described for OpenEMR here:
http://www.openmedsoftware.org/wiki/Git_for_dummies
There's only several developers whom know much about CAMOS development; I'm guessing that by this point you are now one of them… Looking forward to seeing your code.
-brady
Lee,
Thanks for sharing your views on SA. I have heard about SA and was just curious. I agree with you on the Windows issue. There is no way I will ever allow anything Windows in our office again. We drank that Kool Aid for far too long. Since getting rid of Windows, I no longer have to spend my time fixing things. I am like the Maytag repairman for IT support in our office now. We run Linux/OSX and things just work.
-Mike
Brady;
I went through the GIT instructions without success. No matter what I try to do, when I do the ssh git@github.com (and every other command from that point on), I get the "Permission denied (publickey)" error. I have followed the github troubleshooting guide; I have searched the internet for help; I have uninstalled and reinstalled ssh; I have deleted and rebuilt my key files more than a dozen times. Nada. So until I can do the GIT thing, I'm pretty much left to the "old fashioned" methods.
I know there is something painfully simple that is wacked, but I'm not sure what it is. Like I said, I uninstalled and reinstalled ssh, so it should be clean.
Lee
Just FYI:
* Ubuntu 10.10, gnome
* ssh -V: OpenSSH_5.5p1 Debian-4ubuntu5, OpenSSL 0.9.8o 01 Jun 2010
* results from ssh-keygen, RSA option:
lee@vostro1510
/home/lee/.ssh
:lee@vostro1510:~/.ssh$ ssh-keygen -t rsa -C "lee@TBFed.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/lee/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/lee/.ssh/id_rsa.
Your public key has been saved in /home/lee/.ssh/id_rsa.pub.
The key fingerprint is:
84:92:48:50:71:96:55:29:a5:5d:50:81:cd:0f:94:07 lee@TBFed.com
* results of ssh-keygen, DSA option:
lee@vostro1510
/home/lee/.ssh
:lee@vostro1510:~/.ssh$ ssh-keygen -t dsa -C "lee@TBFed.com"
Generating public/private dsa key pair.
Enter file in which to save the key (/home/lee/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/lee/.ssh/id_dsa.
Your public key has been saved in /home/lee/.ssh/id_dsa.pub.
The key fingerprint is:
43:72:8d:43:20:d4:58:2b:33:2f:50:d3:45:d1:56:cf lee@TBFed.com
* results of ssh -v git@github.com:
:lee@vostro1510:~/.ssh$ ssh -v git@github.com
OpenSSH_5.5p1 Debian-4ubuntu5, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com port 22.
debug1: Connection established.
debug1: identity file /home/lee/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/lee/.ssh/id_rsa-cert type -1
debug1: identity file /home/lee/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: identity file /home/lee/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5github2
debug1: match: OpenSSH_5.1p1 Debian-5github2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /home/lee/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/lee/.ssh/id_dsa
debug1: Authentications that can continue: publickey
debug1: Offering public key: /home/lee/.ssh/id_rsa
debug1: Remote: Forced command: gerve tbfed
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Server accepts key: pkalg ssh-rsa blen 279
Agent admitted failure to sign using the key.
debug1: No more authentication methods to try.
Permission denied (publickey).
Lee,
"Agent admitted failure to sign using the key." looks like an issue with SSH Agent on your computer:
http://serverfault.com/questions/139156/ssh-agent-admitted-failure-to-sign-using-the-key
I don't use ssh-agent (no need for password-less ssh logins), so I haven't experienced this issue.
-brady
Also note the above link posts a very simple solution (ssh -add ). Hopefully it works for you.
-brady
Well, it's been nearly a year since my last message. A couple of client issues caused me to have to retrench and rebuild. I'm now "back among the living," so to speak, and will probably start looking into this again.
- Lee