anonymous wrote on Monday, December 14, 2009:
Greetings! Please review this new meaningful use and let me know what you think. Thanks.
bradymiller wrote on Monday, December 14, 2009:
hey,
Looks very cool. Nice to have a mechanism like that in place for other things also such as consenting also etc. Got several questions, but all could be answered if I could see a patch of this derived from sourceforge’s main CVS development tip. Is there a way you could post it on our ‘patches’ tracker here on sourceforge or on your wiki page?
-brady
sunsetsystems wrote on Monday, December 14, 2009:
Nice to see things happening. I do have a couple of questions.
It seems a bit odd to see this type of form uploaded via patient demographics, whereas most uploaded patient-specific form types are in the patient documents area. Why not create a document category “Advance Directives” and put them there?
Also what’s the additional upload function for in the encounter forms administration page?
Thanks!
bo2999 wrote on Monday, December 14, 2009:
For some reasons, when our charts were audited by certain health plan they want us to place the advanced directive form in the demographic section!
Bo,
sunsetsystems wrote on Monday, December 14, 2009:
Hmm. What I like to do with dubious requests like this is to create a feature that can satisfy it, but is more generally/obviously useful. My first thought about this one is to make a new form field type where you can specify a document category at design time, and when used the form field will show the list of documents in that category for the current patient (and allow you to click on one to see it).
Anyway in my experience insurance providers do not always give accurate information… I like to see it in writing.
bo2999 wrote on Monday, December 14, 2009:
To clarify, I think the health plans want to have a check box in the demographic section to confirm that you have review the advance directive with the patient. I think you can put the form wherever you think it is appropriate. The check box could be similar to the HIPPA box!
Bo,
sunsetsystems wrote on Monday, December 14, 2009:
Bo, yes that makes sense.
anonymous wrote on Tuesday, December 15, 2009:
Hi Brady,
I will do that when I figure out the process to move from CCHIT project to SourceForge.
==
Hi Rod,
The file upload in Administration is for uploading form templates (blank forms), while the file upload in Demographics section is for uploading completed forms.
Bo has helped answer the placement question. Advance Directives are also important for urgent care. So it must be easily found.
bradymiller wrote on Tuesday, December 15, 2009:
Thomas,
Still interested in seeing the code, but figured I’d post my two cents so far. This seems like a really overly heavy weight solution. As Rod suggest, why not simply upload the advanced directives into a set category in the documents module. Then could simply add some entries to the demographics layout\_options table and the patient\_data table. Then code on the demographics page could check status on the ‘Advanced Directives’ documents and patient_data entries, and throw out an appropriate indicator/warning. Thus, couldn’t the criteria simply be fulfilled by the following changes to the three below files:
**openemr/sql/database.sql**
- Place a ‘Advance Directive’ item in categories table
- Place the three new fields in patient_data table (‘Completed Advanced Directive’,‘Type of Advanced Directive’,‘Last Reviewed Date’)
- Place these three new fields in the layout_options table in the Choices category
- Place the list of potential Type of Advanced Directive choices in the list_options table
<br>
**openemr/sql/3\_1\_0-to-3\_2\_0\_upgrade.sql**
- Place stuff added to openemr/sql/database.sql for users upgrading
<br>
**openemr/interface/patient_file/summary/demographics.php**
- Simply include a code block that then collects info on ‘Advanced Directive’ documents (from documents table) and info from the patient_data table via mysql queries. Then could display the appropriate info/warning in the top right. What’s nice about this is that it can easily be turned off via a interface/globals.php switch if user doesn’t want it. This code could also easily be used in other places (ie. when we have a clinical reminder page in the future).
<br>
Am I missing something here?
-brady
bradymiller wrote on Tuesday, December 15, 2009:
hey,
Just realized my above scenario doesn’t have the ability to enter in the titles and multiple ‘Advanced Directive’ forms. To do this, would then not include the ‘Type of Advanced Directive’ in the patient_data or layout as described above. Could create a ‘title’ column in the ‘documents’ table, which could enter in when import the file into the ‘Advance Directives’ category (could even use a selector to force an appropriate selection from the list\_options table).
-brady
bradymiller wrote on Tuesday, December 15, 2009:
Also, I’m just thinking out loud here. This is in no way meant to be “do it this way or else”; just discussing possible coding strategies.
-brady
drbowen wrote on Tuesday, December 15, 2009:
Dear Thomas, Brady and Rod,
The current location was my suggestion. The Advanced Directive is a document not like any other. It has special emotional, social, and legal meaning. As such I wanted the controls to be visible in a very high priorty area and chose the demographics section for this. The actual storage location of the pdf can be the usual documents file. I worked in our local hospital’s emergency department and had primary responsiblity to respond within 2 miountes for full caridac arest. I taught ACLS, PALS, BTLS, and was an affiliate faculty member of the Amercian Heart Association where I set up these eduacational prohrams. I was always arriving on the scene where half the people present were panicing and it was my job to restore a working team for the resuscitation. I cannot count the number of times that the staff had no idea what the resuscitation status (Advanced Directice Status) was and half the time they hadn’t tried to check vital signs.
When a patient is pulseless with no blood pressure. Everyone panics. This document has to be immediately available when the entire office staff has forgotten how to read, forgotten how to add, panic takes over and erases the majority of your education. The presence of a valid Advanced Directive in my opinion ought to glow bright red and be viisble on the first summary page of the patient’s EMR. It is the only type of lettering that a panicing person can read or find when the Advanced Directive is needed in a hurry.
Sam Bowen, MD
sunsetsystems wrote on Tuesday, December 15, 2009:
Just an idle thought: “Type of advanced directive” could be a sub-category of the Advanced Directives document category, instead of a list.
I’m interested to know more about the “form templates”. Are these blank forms like PDF files? So that the work flow is: print a blank form, have the patient fill it in and sign, scan it into documents? One interesting part of this problem is it’s not patient-specific and doesn’t fit well into any existing section of OpenEMR (the existing forms administration page is all about encounter forms). The Address Book was also like that, and I ended up creating a new section for it.
drbowen wrote on Tuesday, December 15, 2009:
The fully developed Advanced Directive section would include the State designated blank Advanced Directives. Many people show up with an already signed directive. Others need one an dask the docotr to supply them with one. Unfortunately every state is different and multiple states have multiple forms. We thought this was a bit out of the scope of what we were trying to accomplish with the advanced directives for Meaningful Use. We would like to add these later after Meaningful Use is achieved.
Sam Bowen, MD
sunsetsystems wrote on Tuesday, December 15, 2009:
Sam thanks for chiming in. It’s so interesting to me to see how doctors use the system. This is what it’s all about.
As for the user interface design, could I suggest adding one or more form fields to the demographics layout that summarizes each advance directive in a word or two - e.g. “DNR”? I’m thinking this may be more helpful in an emergency situation because it saves the step of bringing up a document and interpreting what it says.
If that’s not deemed useful, then I will refer back to post #5 in this thread with my suggestion of adding a layout field type that permits read access to the ADs stored in patient documents.
bradymiller wrote on Tuesday, December 15, 2009:
Sam,
Trust me, I have also experienced the confusion of unknown code status during codes that you discuss. In my training, the VA/CPRS was the best system and alleviated any confusion by putting a code status indicator at top right of the main screen. I am in agreement with you that it needs to be on the main demographics screen, and this is where I put it in my proposed coding scenario. This indicator could show a link to the document(s), name of document(s), and whether it’s due to review it. This indicator could also easily be turned of via interface/globals.php (ie. acupuncture clinics do not need this).
The things that seems really awkward to me are:
1) The obtrusive(and heavy weight) method of uploading the documents in the demographics input form.
2) The uploading widget in the admin->forms. I can’t even figure out why this is even needed; seems like just a simple file repository. Nobody has ever requested this type of feature, since offices probably have their own mechanism for printing/storing paper forms.
3) Also, a patch is worth a thousand words. Please try to post it.
Using Rod’s suggestion of sub-categories, my above proposed coding scenario gets even easier(total of about 25 lines of code or so). Here it is:
**openemr/sql/database.sql**
- Place a ‘Advance Directive’ item in categories table
- Place ‘Living Will’, ‘Durable Power of Attorney’, ‘Do Not Resuscitate Order’ items in categories table as subcategories of ‘Advance Directive’
- Place the two new fields in patient_data table (‘Completed Advanced Directive’,‘Last Reviewed Date’)
- Place these two new fields in the layout_options table in the Choices category
<br>
**openemr/sql/3\_1\_0-to-3\_2\_0\_upgrade.sql**
- Place stuff added to openemr/sql/database.sql for users upgrading
<br>
**openemr/interface/patient_file/summary/demographics.php**
- Simply include a code block that then collects info on ‘Advanced Directive’ documents (from documents table) and info from the patient_data table via mysql queries. Then could display the appropriate info/warning in the top right. What’s nice about this is that it can easily be turned off via a interface/globals.php switch if user doesn’t want it. This code could also easily be used in other places (ie. when we have a clinical reminder page in the future).
<br>
-brady
drbowen wrote on Tuesday, December 15, 2009:
Thomas is still in the “new kid on the block” category. I will see if we can get you dif -u patch. If you want we can get you SVN privileges at http://openmedsoftware.org. This would make looking at this code easier for you.
It would be nice if we had a color coded box, green for full resuscitation, orange for limited, red for “just let me go”. I will talk it over with Thomas.
Sam Bowen, MD
bradymiller wrote on Wednesday, December 16, 2009:
hey,
A patch is by far the easiest. Then can just focus on the changes and provide quick feedback. There are quite a few pitfalls in using (or even worse, not using) the Documentation class. Creating patches is a good skill for a developer to learn.
Regarding your color coded box, would be simple in my above scenario to add to the database.sql file another column in patient\_data to hold code\_status along with corresponding entry in layout\_options and list\_options(holds options Full Code, DNR, DNI, DNR/DNI). Then all info can be collected by the indicator in demographic.php, and anything can be done with it (color, funeral procession music, etc.).
I’m a bit wary of having a code status toggle, though. If you didn’t know the patient, would you be ok with not coding them because of a red DNR/DNI box on the EMR that anybody could change; wouldn’t you rather simply click the link to the ‘Do Not Resuscitate Order’ in the indicator and read it for yourself. If I had a vote, I’d vote for no code status toggle and a color scheme that would be red for no Advanced Directive or need to review it, and green if it exists and up to date. I would then place titles of docs in the indicator with links to them.
-brady
anonymous wrote on Wednesday, December 16, 2009:
Hi Rod,
There is a field for naming/describing a form when you upload it. This is to take care of the different types of forms. See
http://www.noah-health.org/en/rights/endoflife/adforms.html#Alabama
There is even a form for Anatomical Gifts in Missouri. (BTW, the list is not complete.)
Each state has their own legal definitions and names. If we want to set the names for the fields, then we would need to do a comprehensive legal research. We decide that it’s better to let the users manage the legal aspects of Advance Directives.
===
Hi Brady,
I think your question is why we put the blank forms in Administration > Other > Forms section, and your suggested coding approach is for putting the forms in Documents section.
We actually considered Documents but decided to go with Forms because it makes more sense from a user’s perspective. I did a lot of configuration work with Epic systems in the past. One of the common requests is to move buttons and menus to locations where they make more sense from a clinical user perspective.
Here, the blank forms are to be uploaded by the Administrator. So the logical location is to put them in the Administration section and not the Patients section.
Why do we want to upload blank forms? Well, the whole idea of electronic health records is to minimize the use of paper charts and forms. Why print out hundreds of forms when you don’t need them right away? And when you do want to print them, where can you find the master copies?
As for why there are upload fields in Demographics, they are done to match the user’s expectation. That’s where they fill in the demographic information and look for Advance Directives. That should also be the place to upload completed Advance Directives documents. We do this to make it easier for the user.
We will add the SQL codes to openemr/sql/3_1_0-to-3_2_0_upgrade.sql file. That seems to work for a new installation only as it removes existing data in the system. Please correct me if I’m wrong.
==
As for coding, we would use the existing codes as much as possible before attempting to create new ones. We are a believer in standardization. I know you are anxious to look at the codes. I agree with Dr. Bowen that it would be easier if you have SVN access. For now, please email me at “thomaswong.usa @ gmail.com” so that I can send a copy to you.
Are you available for code questions? If so, we can consult you during the coding process. This way, we can start the discussion early and avoid any unnecessary rework.
sunsetsystems wrote on Wednesday, December 16, 2009:
I have to agree with Brady. The thing is that these AD forms are exactly the kind of thing that the Documents section is for. Honestly I don’t see how users can think it natural to load them into patient demographics. Otherwise, why not every other kind of document image also?
OK sure it can be important to find them quickly. But that’s true of lots of things, and we’ve already made suggestions for how to easily satisfy that desire in a more flexible and less invasive way.