ideaman911 wrote on Wednesday, April 08, 2009:
The prior version had the ability to change a field from Who the Choice for example. I find no way to do that now. The "Move Up" moves ALL of a type, rather than an individual one. We should have the ability to move up and down any single data field and continue through all the choices if we want to follow a GUI approach as currently shown.
Joe Holzer Idea Man
http://www.holzerent.com
cfapress wrote on Wednesday, April 08, 2009:
Hi Joe,
It sounds like your just trying to re-order a single field within a group. In each group there is a column labelled ‘Order’. There, you can reorganize the order of the fields within a group. Originally I had developed a drag-and-drop method, then changed to an up/down arrow, but finally relented and stuck with the original method of hand editing the value in the Order field. It really came down to just how much time I could devote to OpenEMR development.
Jason
ideaman911 wrote on Wednesday, April 08, 2009:
Jason;
Actually, I want to do as I indicated - move a field between groups. My client has need for some of the fields to be visible immediately on viewing the Patient default Who view. She does house calls so wants things like Firearms & Extinguishers/Detectors right up front.
I am pretty certain it can be done within the Admin - Databases by manually editing the “Group” there. But that is frought with peril, especially in the hands of users, so I’d prefer to have it externally in the Layouts capability as before.
I already knew about the "order" capability. Thanks.
Joe Holzer Idea Man
http://www.holzerent.com
cfapress wrote on Thursday, April 09, 2009:
Ah,
There is no feature to move a field between groups. Never has been. It would be a nice feature. There is at least one peril that needs to be carefully observed. If there is already data in that field and it is moved to another group, will it affect the existing data? Or will it simply be moved? I don’t know the answer to that right now. The underlying mechanics of the layouts is pretty complex. If nobody else picks up on this thread in the next few days I’ll take a look at it myself.
I’m interested in changing how the layouts are displayed on the screen. I’d like to see them changed from toggle-checkbox style to tab-style.
Jason
ideaman911 wrote on Thursday, April 09, 2009:
Jason et al;
I can explain from the 2.9.1dev w/ Xampp 1.4 experience that we had only to change the word "Choices" to the word "Who" (actually, it was the Misc stuff we moved mostly, but a fer of the Choices) in the <3 version and it brought all its data fine because we merely changed its display location on the screen, not the data it posted, etc.
One other comment: the ‘X’ on the far left is way too easy to click and DELETE COMPLETELY. Can we at east label it as “Delete”, or make it an “Are You REALLY Sure” type where they have to hit a ‘Y’ in order to actually do so. I scared the hell out of myself. I can just imagine the problems that will cause users.
Joe Holzer Idea Man
http://www.holzerent.com
tmccormi wrote on Thursday, April 09, 2009:
Joe is correct, I used changing the word 4Misc to 1Who to move a usertext box to the Top group. May have been an unintentional feature in 2.9 but it was a good one.
I’ll bet you can still do it in the database directly on the layout_options table, group_name field.
–Tony
www.mi-squared
ideaman911 wrote on Thursday, April 09, 2009:
I have to learn to type one of these days. The "fer" is supposed to be "few". Also, we changed relative locations in the group with changes in the column "Order" number. Hope that helps.
Joe Holzer Idea Man
http://www.holzerent.com
tmccormi wrote on Thursday, April 09, 2009:
Joe - I see you opened a bug in Tracker on this, that’s a good thing. When you do that, however, make of note of it in the thread that spawned the issue in the Bug and a note of the Bug ID and header in the thread so the developers know it’s there.
New Bug entered:
Can’t move individual fields in Layouts - ID: 2742631
Tony
Unofficial, self appointed, Tracker Database nag …
cfapress wrote on Monday, April 13, 2009:
Hi All,
I’ll try to address each point as clearly as possible:
1) The ‘X’ button
This is the way to remove a field completely from a layout. When it is clicked a popup window appears warning you that the action cannot be reversed. If you click ‘Yes’ then the field is deleted. If you click ‘No’ nothing changes and you are returned to editing the layout.
2) Order of GROUPS
The groups are displayed in their distinct order in the editing screen. For example, the ‘Who’ group is before the ‘Choices’ group in the edit layouts screen. This means that the ‘Who’ group will appear before the ‘Choices’ group when editing the demographics of a patient. You can move the ‘Choices’ group UP so that it comes before the ‘Who’ group simply by click on the “Move Up” button right next to the ‘Choices’ group label.
3) Order of FIELDS
Within each group are fields. These are in numerical order. You can see the order in the far left column. The order can be rearranged by changing the numeric values. NOTE this only changes the order of the fields within the group.
4) Moving a FIELD
You cannot move a field between groups. I’m looking into this but right now, due to the underlying logic and design, you need to delete the field from the old group and create a new field, with the exact same name, in the new group. It is possible to use phpMyAdmin to move a field between groups as I did not change any of the underlying logic; i.e. All group names are #<txt>, such as 1Who and 2Choices.
I’ll play around a little to see what’s going on. I’ve already uncovered an unintential bug relating to layouts and saving of demographics.
Jason
blankev wrote on Monday, April 13, 2009:
Jason,
since you brought it up, if there a way that I can make change in some Characters (Characters that I woulod call LABELS, in OpenEMR that I want to change, but do not show up in lang_definitions can I change some of them in lay-out fields.
Or is it possible for me to make a lay-out field and than change the Label (?)…
How can I include " $ " the Dollar sing or make the " $ " asign a label and have this used in Layouts to change currency and not bring all $VARIABLE names in a psycho-stress situation?
Pimm
cfapress wrote on Monday, April 13, 2009:
.
WOW |:.
Ok, I think there’s a monster bug lurking and I was the mad scientist that created it.
I did not realize that when a field is added/removed from the Demographics layout that the patient_data table has to be altered as well. I believed there was another table that stored the related patient data. (Wouldn’t that be nice?!) So, I’ve got to dig into the code and create the necessary ALTER TABLE commands to fix this bug.
YIKES!
Yet again, the deep integration between code and data strikes hard!
I committed the bug fix to CVS this morning with added logging too.
I have not figured out the best way to allow a Field to be moved between Groups. There are any number of methods. I’m thinking of a popup menu that allows a Field to be moved or deleted. The button that now only deletes could be turned into a multipurpose one that brings up a popup window to choose: Move or Delete.
Jason
cfapress wrote on Monday, April 13, 2009:
BAH!
Murphy’s Law is going strong today. Yet another bug turned up. Not only does the patient_data table need to be altered for each addition/removal of a new field, the transaction and history_date tables need to be altered too. I’ve just made the code corrections and applied them to the CVS code base. Even more… if the global value ippf_specific is set then three more tables could also be altered.
I think I’ve caught up with everything now. But please, I need some additional testing by you. So, if you have a chance, update your development code with the changes I’ve made to <oemr>/interface/super/edit_layout.php
Jason
tmccormi wrote on Monday, April 13, 2009:
Be careful with the alter table :-) The newPatientData add function appears to use field order inserts versus field name mapping and might bite. updatedatePatientData is using field name mapping, much better.
–Tony
www.mi-squared
drbowen wrote on Monday, April 13, 2009:
Jason,
I guess you know now but:
Demographics layout == patient_data
The problem that I see from the current demographics page is that there are too many helpful little programs that cannot handle more general solutions.
We don’t have enough name fields.
We need a minimum of four. In US English we need a full first, full second name, full surname and a "nickname."
Spanish needs a full first, full second name, two full surnames (for mother and father) and a "nickname."
Dutch needs five names
The dates should be convertible into whatever is normal for the local.
The telephone number works great if you are in the US and are not at your business and don’t have an extension number.
Again we need more flexibility in the telephone numbers.
Sam Bowen, MD
ideaman911 wrote on Tuesday, April 14, 2009:
While we are "Yikeing":
a) In addition to the current names fields, we will need to double them once this is all done, to meet CCHIT AKA requirements. Might as well do it now.
b) If we are doing this much with fields, we should also fix the limits on text, ie anytime we enter a cap it should be a cap, an asterisk is an asterisk, an apostrophe… etc.
c) If at all possible to do so, when we move from any field to another field it should post as though we pressed "Save", rather than needing another step. That is also the time to check against whatever "format" tests we wish, but we must make them flexible enough to accommodate NON-standard. For example, I know there are phones in Europe which have both seven and eight digits within the same "area" codes. Same for dates. It seems to me that a subroutine which checks the data block for formatting could "propose" but accept whatever is revised.
d) Jason; since both Tony & I used the 2.9.1 method without problems, what were the changes to the structure of the data which are now a problem? If it is ONLY the new presentation, perhaps we should return to the prior presentation until you get the bugs ironed out of the new presentation? I have a similar issue, I think, with the new Encounter link edit of Camos; it displays twice. But if you edit the upper of the two, it seems not to take, while the lower does. I suspect it relates to Mark’s comments in the PHP, since it seems to only display for the first camos, but I could be VERY wrong, and have only briefly looked at it.
Joe Holzer Idea Man
http://www.holzerent.com
sunsetsystems wrote on Thursday, April 23, 2009:
This design of having the X button remove table columns is not working. We cannot just delete columns from the patient_data table for example. Other code assumes they are there, and things break badly. There is no way the user can or should expect this, in spite of the warnings.
I’m not sure it’s a good plan to add columns either. That’s what the “user defined” fields were for.
Could I suggest that these add/remove features be removed until a more comprehensive solution can be implemented?
tmccormi wrote on Thursday, April 23, 2009:
I concur with Rod’s conclusion.
Long term I would suggest that all user defined type fields be contained in a separate table from the base demographics. And, therefore not arbitrarily limited by field names like usertext# but definable by the user.
Tony
cfapress wrote on Wednesday, April 29, 2009:
Sure, we can take back the new functionality quite easily. Just rollback some of the files to prior CVS versions and then check them in as ‘new’.
Perhaps the edit-layouts screens should allow the addition of groups and fields but not allow the removal of key fields such as name, address, etc.
Jason