A simple example would be to add a calculator like a cardiovascular risk calculator. This might take a user an hour or so to do.
Or, if you were doing oncology, calculate doses for iv infusions of chemotherapy drugs based upon surface area.
Or, if you were doing obs, a pregnancy calculator.
Graham http://www.synapsedirect.com/ Synapse - the EMR for smart users
We can all do custom controls so (general) calculators are too easy - its also a fairly common function in EMR's.
All the requirements for chemotherapy are considerable with as much about preventing the user from doing the wrong thing being more important then having a excessive functional needs.
I am working on my medications screens and workflow as we speak and have great interest in addressing Oncologies issues which will set us apart from large vendors.
Greg
http://www.patientos.org
Custom controls are easy to do for the vendor, but not so for the user.
Here's a calculator example I just did to show how easy it is
panel white 220x140 data [ label "Surface Area Calculators" return group-box "2.5 - 20 kgs" -1x-1 data [ after 1 label "Weight (kgs)" sacalc1fld: field 20 button "Calculate" 20 [ use [wt] [ wt: to-decimal sacalc1fld/text set-text sacalf2fld form-decimal (0.036 * wt + 0.09) ] ] label "Result m2" sacalf2fld: field 20 ] group-box "20.01 - 40 kgs" -1x-1 data [ after 1 label "Weight (kgs)" sacalc3fld: field 20 button "Calculate" 20 [ use [wt] [ wt: to-decimal sacalc3fld/text set-text sacalf4fld form-decimal (0.025 * wt + 0.33) ] ] label "Result m2" sacalf4fld: field 20 ] return text "Lindahl S, Okmian L. Bedside calculation of body surface area for infants and children. Critical Care Medicine. 1981; 9: 778-779."] #HW
which gives the following appearance in the custom tab
So in PatientOS with the current 0.51 release (no new code needed) here is one way of doing it
a) Create a new Form for your calculator and bind to a button or in this example edit an existing formb) Add 2 controls (I could do a calculate button but I don't want one)c) Weight input and Calculated Result will be my two fields (I don't need to add 2 seperate controls)d) The properties of the Weight Input control each are in figures 2 and 3e) The properties of the Calculated Result control is just a text field with a Context added (fig 5) so it can be referenced (fig 4)f) Since the form is in the context of a patient I will default the weight into the input box for fung) When the user tabs out of the input box the calculated result is displayed (you can test it in the form editor as it is almost WYSIWYG)
Note we use Javascript - an industry standard language for any and all scripting of controls, rules, custom business logic etc.
You could get a lot fancier - I could add a label on the right which shows the calculation, I could display text if the input was not within valid values, you lookup any database values and go where ever your imagination takes you.
But back to Medications implementation for me - as this form simply will not do :-)
Greg,
I'm a little unclear here. Is your client application written in Java, but uses javascript as it's scripting language?
ps: my calculate button was not needed either as it can force calculation on loss of focus from the text field, but I added it for clarity.
Yes, exactly right. Java is the UI - but the actual layout and properties of all those Java GUI controls, forms, menus, toolbars, dialogs, etc are all defined in the database. All of the UI is generated at runtime based upon that database content (which Java does anyone so it is still very fast).
You can use PatientOS tools (like the Form Editor) to modify the database content and thus the UI. I use the Form Editor and other tools to build the entire application with all its bells and whistles. The end user gets some simple to use tools to personalize the UI but more importantly the IT staff get to use all the tools I use - thus they have 100% control over the look, feel, content of the application.
Javascript is used where ever it makes sense for administrators to be able to insert business logic, handle workflow. Since the javascript can access all the Java classes and API with a few lines of code you have a lot of possibilities.
caultonpos: Yes, exactly right. Java is the UI - but the actual layout and properties of all those Java GUI controls, forms, menus, toolbars, dialogs, etc are all defined in the database. All of the UI is generated at runtime based upon that database content (which Java does anyone so it is still very fast).
Certainly sounds very flexible.
As I step back and look at the bigger picture, I cannot think of one of our physician users who wants to create tabs and write controls from scratch. I think that is far different than right clicking to add/alter/delete clinical content from a template or to right click and add clinical content to a screen. I think foremost, users need good tools for those things they find themselves needing daily.....and that is easy access to relevant clinical content. That is not to say that what you present is not cool, but it might not be terribly relevant to what is needed. For example, there are C-scripting languages that I could incorporate into Medtuity, but I think I will wait until there is some inkling of need by our users.
If I'm proven wrong, I'll drop in an interpreter.
These type of tools are not for end users (in my mind) they are for the analysts or IT staff implementing the EMR in the first week or two.
In the case of a hospital system (which is where I am heading) it is for the IT department to use to rollout the system to different services, different departments that have varying needs. Chemotherapy is a good example where the vanilla medication order entry will never cut it and different hospitals will have radically different policies and procedures which are impossible to meet in a canned product - you need flexible tools to customize the implementation.
My 2 cents.
This is definitely very flexible. The question that comes to my mind is how are these customizations going to be supported. If you have hundreds, hopefully thousands, of customers out there with custom code, written by them, how do you plan on providing them with support? It could get very expensive....
Margalit
Margalit Gur-Arie
Purkinje
www.purkinje.com
Margalit, that's a silly question! You of course charge them for supporting their custom extensions!!
That's how the open source market works.
Oh....I see.... I didn't realize that this is an open source discussion....
Greg's patientOS is open source and I presume that this is one of the ways he will generate some income.
Mine is not, but the same applies
Charging for professional services to extend a system is common in commercial systems too. The majority of the people that are going to do that kind of customization are either businesses selling services or hospital IT staff. For the average physician office the goal is to have an excellent working product out the box - but I would rather empower the support staff to be able to handle important requirements without a new software release with every change (that becomes expensive).
Custom scripting should still be fairly simple stuff - navigation, popups, default values, simple logic, etc. and this is fine as long as you retain control over the system and understand how the API works given the range of input values that could be passed.