Is anyone developing custom HTML forms? I have seen Blackbird Solutions forms, and I liked what they did. So, I decided to start looking into this because it looks like it has great potential and can really change how we display forms and gather data.
Questions I had while creating HTML forms:
What is your debugging process?
- I have a tough time debugging because the HTML forms are stored on the jboss server (C:\Program Files\Centricity Practice Solution\jboss\server\default\deploy\<database_name>.ear\CentricityPracticeWS.war\EncounterForms), but the only way it will recognize any updates is if it is in a new folder. So, I have to create a new folder every time I make a change to test.
What IDE do you use to speed up the HTML/CSS coding process?
- I have tried a few out there, but I haven't really found any that I like. I wanted something that made a simple drag and drop interface for creating the HTML/CSS code (maybe also the javascript?). I have some tools that help speed it up, but it still takes a lot more time than creating it in VFE.
I would be interested in learning more about the HTML forms development to debugging to creating the Clinical Kit for import.
mikeseale - what developer tool are you using to create HTML forms and is it efficient?
abulsara - These are actually sitting on your JBOSS server instead of being stored in the SQL database. So, the only CKT file that would be involved would be the form that has a link to your HTML forms. I can work on writing down my current process of adding an HTML form.
adaniel - I'm currently using NetBeans that creates an HTML5 application (can handle HTML, CSS, and javascript). It's okay for now and free, but still takes a long time to design a form.
So I'm assuming any html developer (Expressions, dreamweaver, etc) can accomplish this?
Yeah, I would think anything would work for this. You just have to be sure to have the javascript libraries that hook into CPS established in your project. That way you can do calls like this:
vUsrLoginName = Mel.eval("{USER.LOGINNAME}");
The current GE HTML forms use Mel.eval to write to a document variable in the open encounter, so when you close the HTML form, all your data is back on the chart note.
I wonder if you could indicate in the HTML tags not to cache the page to help with debugging so that a new version loads. Or maybe there is a JBoss setting to not cache pages. Otherwise I would think the only way to avoid the new folder issue when debugging is to cycle the JBoss service. That would be fine if you are the only one in Test but it might crash other clients if they are connected.
For HTML form development I'm using $mdObject with Simulator so, I can build all HTML pages in Microsoft Visual Studio 2013. The demo.html page will show you a lot of features (AngularJS, bootstrap and all $mdObject properties and methods). The Simulator allow you to build an HTML page without Centricity installed. The Simulator is in beta. If you are interested in Simulator just contact me directly and I will send you a link to beta.
The HTML forms are very cool. You can call web services (with jQuery or AngularJS). Design is way more sophisticated. With $mdObject you do not need to learn MEL. If you know JavaScript and HTML you can build very advanced forms very quickly.
To try $mdObject demo just drop all files under folder bellow (for demo db) .
C:\Program Files\Centricity Practice Solution\jboss\server\default\deploy\demo.ear\CentricityPracticeWS.war\mdObject\
Make sure you copy all scripts files as well. Create a Quick Text in centricity:
.mdobject
{show_html_form("//localserver/mdObject/Demo.html","mdObject Demo")}
And call it from Text of the new document.
HTML Forms are always cached. To open always a fresh copy of the HTML form the META directive need to be added to the HTML form. Enter the following META tag between <head> and </head> tags:
<meta http-equiv="PRAGMA" content="NO-CACHE"/>
<meta http-equiv="CACHE-CONTROL" content="NO-CACHE"/>
Note that the second meta directive currently has no effect on caching. The second directive will be used for HTTP/1.1 protocol.
For those of you who have been working on custom HTML forms, relative to MEL forms how have things looked performance wise? Loading during a visit, clicking around the form, etc.
Thanks,
Brad
bhoover:
HTML forms are VERY responsive and fast. The reason for this is because you now are able to control what is updated/ran whenever you click through the forms. In MEL forms, anytime you assign a value to an observation term, the form will go through EVERY observation term in your form and update it. This is what causes most of the slowness in bigger forms.
The only drawback is that the form isn't embedded in CPS, so I get a lot of kickback from providers and nurses about how different it is (they hate change).
mikeseale: What do you mean "the form isn't embedded in CPS". What about Immunization form? Do you consider this form "embedded" or not?
bhoover: I agreed with mikeseale. HTML Forms are very fast. I could load almost all patient data for less then 3 sec. I built very sophisticated forms. UI and form performance are outstanding.
aaltotsky:
By not embedded I mean that the HTML forms aren't in the same window as the MEL forms. They pop out into a new window that has to be closed before moving on. So, if you have a mix of MEL and HTML forms, the experience isn't very consistent. So, I'm trying to move all of our forms to HTML.
mikeseale: Thank you for clarification. You are correct: user experience is match better to use only HTML form. In fact as it's new technology, GE most likely will move existing form to HTML as well.