Menu

CCHIT - Advance Directives

Developers
Anonymous
2009-12-14
2013-04-06
1 2 > >> (Page 1 of 2)
  • Anonymous

    Anonymous - 2009-12-14

    Greetings! Please review this new meaningful use and let me know what you think. Thanks.

    http://www.openmedsoftware.org/wiki/Advance_Directives

     
  • Brady Miller

    Brady Miller - 2009-12-14

    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

     
  • Rod Roark

    Rod Roark - 2009-12-14

    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!

    Rod 
    (http://www.sunsetsystems.com/)

     
  • bowyn

    bowyn - 2009-12-14

    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,

     
  • Rod Roark

    Rod Roark - 2009-12-14

    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.

    Rod 
    (http://www.sunsetsystems.com/)

     
  • bowyn

    bowyn - 2009-12-14

    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,

     
  • Rod Roark

    Rod Roark - 2009-12-14

    Bo, yes that makes sense.

    Rod 
    (http://www.sunsetsystems.com/)

     
  • Anonymous

    Anonymous - 2009-12-15

    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.

     
  • Brady Miller

    Brady Miller - 2009-12-15

    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

     
  • Brady Miller

    Brady Miller - 2009-12-15

    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

     
  • Brady Miller

    Brady Miller - 2009-12-15

    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

     
  • Sam Bowen

    Sam Bowen - 2009-12-15

    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

     
  • Rod Roark

    Rod Roark - 2009-12-15

    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.

    Rod 
    (http://www.sunsetsystems.com/)

     
  • Sam Bowen

    Sam Bowen - 2009-12-15

    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

     
  • Rod Roark

    Rod Roark - 2009-12-15

    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.

    Rod 
    (http://www.sunsetsystems.com/)

     
  • Brady Miller

    Brady Miller - 2009-12-15

    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

     
  • Sam Bowen

    Sam Bowen - 2009-12-15

    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

     
  • Brady Miller

    Brady Miller - 2009-12-16

    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

    Anonymous - 2009-12-16

    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%C2%A0

    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.

     
  • Rod Roark

    Rod Roark - 2009-12-16

    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.

    Rod 
    (http://www.sunsetsystems.com/)

     
  • Anonymous

    Anonymous - 2009-12-16

    I invite you to look at it from the user perspective. My point is that the location of the file upload depends on the location of the file download. Here's what the user would need to do if the file upload is in Documents section:

    1. The user opens up patient Summary and sees that Advance Directives are not there. This can be when creating a new patient or updating a patient record.

    2. The user clicks on Medical Record. The category tree expands.

    3. The user clicks on Documents. The Demographics screen changes to Documents screen.

    4. The user clicks on Advance Directives to get to the file upload field. The user uploads a file.

    5. Now, the user wants to know if the file is listed in Demographics. So he clicks on Management. The category expands.

    6. The user clicks on Current. The Documents page switches back to Demographics.

    7. The user clicks on (More). Now the user is back on the Advance Directives page where s/he starts the process.

    So by using the file upload in Documents, the user has to perform 7 extra clicks.

     
  • Anonymous

    Anonymous - 2009-12-16

    Hi Rod,

    In terms of image, I can think of patient photo. The natural way of uploading a photo is in the Demographics section and not in Documents. This is what I have seen in several EHR systems. I would suggest we don't limit file upload to a specific area. On the backend, yes, we can and should keep all the files in the same folder (and/or subfolders).

    Please note that if you really want me to move the location and if Dr. Bowen is ok with it, I will gladly do so. I do want to express my thoughts on this topic.

     
  • Brady Miller

    Brady Miller - 2009-12-16

    Thanks,
    Thomas for sending the file. I put a patch of it compared to our curent CVS in our tracker (wiki is not allowing zipped uploaded file, so in tracker for now):

    My take on this:

    1) There has already been significant divergence of the this "project" code to ours on CVS (several months I'm guessing). Tony, please consider getting your code updated.

    2) There has been no apparent use of the mechanisms that OpenEMR already provides; instead they were either bypassed or re-created, including things such as:

    - Layouts
    - Document management
    - Internationalization

    <br>
    I think the problem is your coding strategy is going in the wrong direction. You are starting with the visual layout and then creating functions/structures around that, which does not work in OpenEMR. I think of OpenEMR as an old,stable  machine with many moving parts and some good time tested code. One of these pieces is the document manager; instead of using it, you completely bypassed with, thus your documents do not exist in OpenEMR and lose support for reporting,blobs,etc. Instead, work on getting all the pieces/information in the code, and then work on the layout. My proposed scenario above should be your staring point and can be used to get all your pieces of information in there by using what OpenEMR has already given to you in just 20 or so lines(at this point Meaningful use requirements are done). When you go through those steps and understand it, you'll realize how powerful the layout_options tables and the options.inc.php file is and how to use them properly. Then at that point you can build the upload (if that is the decision) mechanism into OpenEMR's demogrpahics screen by building the control into the options.inc.php library using the functions/library/classes from the current document module.

    -brady

      : http://sourceforge.net/tracker/download.php?group_id=60081&atid=493004&file_id=355419&aid=2915359

     
  • Pieter W

    Pieter W - 2009-12-16

    It might sound rather stupid, but as a praticing dokter I aggree with Sam B. that some medical information could be of very much emergency  importance.

    Please ignore if I did not understand this discussion.

    "Code Blue"  and everybody knows what to do and starts running!

    Why not make a little blue square in a little used corner of the screen. Right lower corner? Make it blue when there is information gathered in this special form and make it invisible if the very special emergency document is without information.

    Let this little square open a new browser HTML screen that can be consulted. Change with ALT+TAB to change backt to the OEMR screen is quick and easy. Both options should work in LINUX and Windows.

    It is obvious that this square should be available within the ACL restrictions and visible with HIPAA permissions, could even have a special password that only the person in charge knows and have to be replaced within a reasonable timespan, or after any use to open this special screen.

    If this could be implemented than there is only a discussion left as of where to make the input of this special Browser screen.

    Pimm

     
  • Rod Roark

    Rod Roark - 2009-12-16

    Hi Thomas,

    Regarding click count, if it makes a difference to you I can show you a way to easily deal with that.  Otherwise I don't want to drag this thread out pointlessly.

    Much of the concern here is code quality.  It's much easier to stomach having the same feature such as uploading in multiple areas of the system if it is all handled with a single shared well-organized set of code, shares a common document repository, looks consistent and well-integrated to the user, and doesn't force things on sites that have no interest in them.

    It takes time to learn OpenEMR well enough to do such things effectively, not to mention actually doing them.  In the meantime it will surely work better for the team to spend its resources on meeting requirements for certification.  Walk before running and all that.

    To all: Regarding submitting patches, they must be made against the SourceForge development tip.  This is a fundamental requirement for working with the OpenEMR project.  In my view it makes no sense to use a separate repository unless the intent is to fork it.

    Rod 
    (http://www.sunsetsystems.com/)

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.