Notifications
Clear all
Topic starter
Does anyone have any advice or pro's and con's of custom forms vs. ccc forms from GE?
We would like to build our own custom forms to replace ALL ccc forms. Anything negative in doing so?
Thank you in advance for your help.
Posted : June 4, 2015 10:22 am
One thought, we have noticed recently that complex VFE forms can take longer to load than CCC forms when launching an update.
Posted : June 4, 2015 10:27 am
My only thought is to ensure you get all the snomed orders sent for MU based on the required criteria. I'm sure you can make better functioning forms than CCC but some of them have a lot going on in the background that update CQR.
Posted : June 4, 2015 10:55 am
Get learn new HTML Encounter forms. If you are going to invest in form replacement, then do it right. I see no reason for any investment into CCC or VFE when you can quickly build way more sophisticated forms with HTML and JavaScript.
There is a reason why GE moving to HTML Encounter forms. In latest release you see only several forms, but soon you will see much more.
Posted : June 4, 2015 1:25 pm
I wouldn't say that GE is moving to HTML forms in any hurry. While it is true that they are working on moving in that direction, the specification is not finalized nor has it been officially released by GE with a 'green light' for individual development. Most of what has been done in HTML today is low overhead content and not any better than a standard encounter form (some of it resembles the simple multi-line edit fields of the early Logician days - a regression, not progression). Additionally the demand HTML places on JBoss has yet to be proven as a viable alternative if more eloquent builds are utilized (based on my testing, it is not ready for it yet either). And no matter what, you still have to use MEL since everything must port back into the EMR and be translated into the chart note, added to the clinical lists, and database.
Posted : June 4, 2015 11:17 pm
I have to agree with Lee, VFE offers stable flexibility and importing/exporting very easily. It is also a time tested method. We are on stage 2 MU using all custom forms. HTML forms look great but we experience script errors frequently because the JBOSS is struggling. I do see a future for HTML forms but it's not today.
Posted : June 5, 2015 3:18 am
Being multi-specialty, prefer the freedom to design and maintain custom forms.
Posted : June 5, 2015 4:44 am
The JBoss is straggling not with HTML forms, but with the MEL. The HTML forms are static content and JBoss is designed to serve them in the first place. The MEL and continuous access to database are the main root of your problems. Try to use a quick text and run {PATIENT.CONTACTS} and see performance of that MEL symbol. (Do it in off peak time or on the non-production environment)
When I’m hearing negative comments about HTML Encounter forms, I would like to ask a question: how many custom HTML form have you done?
I know many companies are moving with HTML forms. Take a look Qvera (immunization form), Blackbird Solutions (One of the best one HTML Form), STC (immunization form).
Tools. There hundreds of free editing tools (including Microsoft Visual Studio), Open source JavaScript projects: (JQuery, AngularJS, Bootstrap, Google map, Google graph, …) and $mdObject Open Source to build “no MEL” HTML forms.
Learning curve. I put 2 training video at my website (less than 5 min each) and in less than 10 min you will able to create your own HTML Encounter form.
Performance: I can design HTML Encounter form that outperform any CCC or VFE form. Why? No constant database access. Pull data on load and save the data on completion. HTML/CSS/JAVASCRIPT can be cached on the local workstation and minimized Jboss load. JavaScript can be loaded asynchronously.
Features: Try to display dynamic graph (weight vs. height in pediatric form) embedded in VFE. (See https://developers.google.com/chart/ ). Or better yet: create mobile device friendly “responsive” VFE form, that will resize itself on the tablet? My one word: Bootstrap ( http://getbootstrap.com/getting-started/#examples ). Here is my best one: use web services to pull data from other sources (immunization or cancer registry for example)? Does anyone know how to do it in CCC or VFE form? And finally: you can host HTML encounter form anywhere in the world (local IIS or Apache HTTP Server; Azure or Amazon cloud)
On the Centricity Live 2015 GE sent the clear message: “thin client”. That is why in 5 years you will see no CCC forms in the Centricity systems. (obviously I can guarantee that J)
PS. My apology if I hurt feeling of anyone VFE/CCC developers.
Posted : June 5, 2015 6:24 am
Interesting comments. Thank you for sharing. Excepting the snazzy eye candy, 99% of what you describe already can be done within the current form architecture - to include 'one pass' processing. This can also be accomplished without security vulnerabilities or browser/Jscript version sensitivities and session state validation issues introduced by an external process like HTML. Moreover, GE is slow to respond to browser version updates leaving the window open for exploits and errors that have been otherwise been addressed.
That said, not one person disagreed that HTML is the direction things are headed in nor was anyone being negative, but it would be dishonest to state anything but that support within the EMR is not at the level it needs to be at yet. Most HTML designs available today are limited use/narrow focus tools - hence my point of it being a bit regressive at this time, especially since current architecture already does that. And I reiterate, GE has yet to release final specifications for use of HTML, so much is being taken for granted and I cannot help but trust my gut and say some approaches will not be allowed due to stability/compatibility/security issues with the destination platform - the EMR.
Tis interesting however, that you suggest mobile 'app' styled charting. The 'world' has a crush on 'mobile' right now, but the reality soon to hit all EMR platforms is that larger screens, not smaller screens, are what is needed to document accurately, efficiently and most important, safely. Often times, a fair amount of data is required on screen, for sound clinical decision making and effective documentation. I would suggest that anyone claiming otherwise does not grasp the requirements of sitting before a patient and documenting a complete visit, on paper or digitally. Mobile has its place, but it is not in documenting care - not enough screen real estate for that on a mobile platform, nor will there ever be.
Documentation templates are more than edit fields and check boxes. Few claim developing clinical decision support in HTML. Add that to the equation and you end up with an approach that can be equally as taxing as MEL.
Accessing data from registries can be accomplished already, with proper MEL and external closed exe design (VB will do), so I do not see the 'plus one' that you do. I am as excited as anyone regarding the potential for HTML, but as a licensed care giver, I am duty bound to recommend safe and sensible approaches that provide efficient tools whilst conforming to published specification. Unfortunately, HTML does not qualify at this time. We certainly hope that in the future, it does.
PS: You might want to update your website ( http://www.renetusa.com/), there are no links to a video nor mention of actually working with the medical industry.
Posted : June 5, 2015 7:33 am
I just update my profile, but the video on http://mdObject.com website.
Again, I did not want to upset anyone with my comments. I’m very passion about HTML Form Development and the opportunities that they open.
In fact the HTML Encounter form increase security as they can be open in IE11 browser with the entire Centricity be in the IE compatibility mode. So you have higher level of security with HTML forms.
Defiantly you can build anything with custom VB/C# window app, but how it will move you from the thick client. You just add more customization that you will have redo in the future.
As being a professional software developer and system architect for over 20 years, I can see plusses and minuses in any system and able to predict future of most systems and it architecture.
But you right: GE does not give you any information on how to build HTML forms nor tools. You can only gather information by looking into existing form or take an HTML Encounter form Development class. Lack of any documentation is the reason why many people are not jump in to HTML form development.
If you search google for “HTML Encounter Forms” most likely you will not find too many training materials as well.
The “safety” is a big term, but mean nothing without specific implementation details. GE will not build HTML forms if they will not be safe to use. In no way GE will compromise Centricity security just to go to HTML. But you, as developer, (not you personally) can build a form that may compromise security. For example: communicate with your server over HTTP (not HTTPS) protocol.
Thank you to add a lot of interested points to this discussion.
Posted : June 5, 2015 8:23 am
Robust discussion on the topic is what is needed if HTML is to come into its own in our lifetime. LOL!
Posted : June 5, 2015 8:35 am
