Customizing vitals

merlinsilk wrote on Friday, December 12, 2014:

The vitals form has an entry of temperature method - I wonder how I can customize that. My first thought was that the options there would be simply a list that I could change in Admin->List - but that does not seem to be the case - at least I could not find a list for the temperature-taking options.
Anybody knows how - and where - to change that list of options?
Thanks!

visolveemr wrote on Friday, December 12, 2014:

Hello Merlin

The Temperature method list has been hard coded in the file interface/forms/vitals/templates/vitals/general_new.html after the line 170.

You can customize this file to change those list options.

Thanks
OpenEMR Customization/Support Team,
ViSolve Inc
services@visolve.com
Demo’s @ ViSolve Demo Library

cmvincent wrote on Friday, December 12, 2014:

I believe the Vitals form should be a layout-based form (LBF) to make it more customizable for each installation. I don’t know what impact this will have throughout the system and if data would need to be migrated. I’m sure Rod would know the answer to this.

Cristina Vincent
Systems Advisor, International Planned Parenthood Federation of the Western Hemisphere

sunsetsystems wrote on Friday, December 12, 2014:

I agree that would be a reasonable thing to do. Data could be converted at upgrade time, or it could just be an optional new form.

Rod
http://www.sunsetsystems.com/

fsgl wrote on Friday, December 12, 2014:

Downside to greater accessibility would be an increase in users toasting their production copy of OpenEMR. Unfortunately they are the same folks who don’t backup.

merlinsilk wrote on Saturday, December 13, 2014:

Thank you, ViSolve - I was afraid of that :slight_smile:
I really don’t like to hack code that will be overwritten at the next update.
I had been thinking of simply creating a new form for vitals (LBF or xmlforms) but the client is really taken by the one feature that calculates the BMI instantly in the current vitals form so that I can not take that away.

fsgl, are you trying to tell me we should backup??? :slight_smile:

fsgl wrote on Saturday, December 13, 2014:

Just relating some woeful tales from other threads. Pediatricians will be miffed if Growth Charts are sacrificed.

No backup can give users a sympathetic discharge (dilated pupils, pounding pulse, sweating, emesis (hurling), etc.).

Old folks, like myself, can do without the excitement.

bradymiller wrote on Saturday, December 13, 2014:

Hi,

An in between option that would benefit both the project and yourself would be do populate this list from list_options (from a list in Administration->Lists), like is done in most places for these types of lists. Then will be customizable and won’t need to hack code. Since it’s in Smarty not as straghtforward; would break smarty law there and surround a call to generate_select_list() (from library/options.inc.php) within native php tags. Also when display it in report.php, should use the getListItemTitle() function (also in library/options.inc.php) when display it.

-brady
OpenEMR

mdsupport wrote on Saturday, December 13, 2014:

At system level vitals can be treated like laboratory test.
Pros :

  1. Each practice can tailor their own ‘vitals’ - may be even multiple variations of ‘vitals’ based on patient type.
  2. Rod has provided basic generic mechanism in config and recording.
    Cons :
  3. Need to import current data
  4. Need simplified process (one screen).
  5. Need to port graphing as well calculated fields functionality - both needed for lab results as well.
  6. Clean up reporting

cmvincent wrote on Sunday, December 14, 2014:

Because of the calculated BMI and now requirements to show graphing for not just BP for but also BMI and potentially height and weight (we have an associated organization who specializes in adolescents so more detailed tracking is important), it seems the solution to purse is with an LBF. We have implemented the system in 12 independent associations in the Western Hemisphere who each have their own requirements so it’s important to have something flexible enough for that.

aethelwulffe wrote on Monday, December 15, 2014:

Cons on Pros list:

  1. Tailoring vitals IAW clinical measures restrictions is a big thing. the Vitals form is the only encounter form that is kind of a sacred cow at the moment…believe me, I would love to include it as part of other forms and push to form_vitals table, yet not push to the ‘forms’ table (thereby creating a separate form in the encounter in “report” mode.
  2. Moving this stuff to LBF ~= permanent ugly layout (no offense), and makes custom nursing forms much harder to create. Reporting against LBF can also be a challenge.

Pros to Cons List:

  1. Importing current data is just a simple query to add to the patch.sql file, or Upgrade.sql as it may be. Data is in a flat table.
  2. An opportunity to do better vector graphing that works on more browsers.

Some other notes: Height weight, circumferences, pediatrician concerns and all that need to be addressed. While we are at it, we need a “Calculated BMI Status” and a “Subjective BMI Status”. Calculated is fine, but observing that your patient is an Aztec Fireplug allows for “Overweight” to be --> “Normal”.

Patient Age needs to determine the layout and usage. Very young and very old (if Granny drops from 51" to 50.5", she needs to be checked out) both need the growth charts.

In closing, if the Vitals form is sacred, in whatever form, and it is one of the most universally needed and used forms, then it should LOOK, FEEL, and OPERATE slick as buttered ball bearings. To do less is a shameful waste of provider’s time and pride in the product.

1 Like

blankev wrote on Monday, December 15, 2014:

Thumbs up for this synopsis. Now we are at it, can we change the name Vitals.

Breathing frequency, heart rate, temperature are vitals.

Length, BMI, abdominal circumference etc. are almost never called Vitals. These measurements are important, but not VITAL!

mdsupport wrote on Monday, December 15, 2014:

We should also plan for data structures that allow (at least) hl7 based import and export of these readings without an encounter. Think Apple Watch.

aethelwulffe wrote on Wednesday, December 17, 2014:

Hell-to-the-Yeah on the HL7 import. Anyone got any pulse-oxy hl7 output files?

For the name, you have a suggestion? Biometrics?
Vital=(living||life||important)

On the same topic, why stop here? If the measurements are less important, why do we have an algorithm for BMI, and we have nothing evaluating vitals to age and measurements?
http://www.fpnotebook.com/cv/exam/pdtrcvtlsgns.htm

blankev wrote on Wednesday, December 17, 2014:

I like “Biometrics”! Important information with a supposedly constant result. If the result is not following the rules (be it graphic tables, constants etc) there should indeed be a red flag sign to alert.

Although BMI is still very active in the medical community, there are others that think the measurement of the belly-hip ratio might give similar, easy and good result as an alternative.

tmccormi wrote on Monday, January 05, 2015:

I like biometrics. That also means you could develop a new form and not
disrupt their old data until it’s all beautiful and integrated.

Tony McCormick

On Dec 17, 2014 4:34 AM, “Pieter W” blankev@users.sf.net wrote:

I like “Biometrics”! Important information with a supposedly constant
result. If the result is not following the rules (be it graphic tables,
constants etc) there should indeed be a red flag sign to alert.

Although BMI is still very active in the medical community, there are
others that think the measurement of the belly-hip ratio might give
similar, easy and good result as an alternative.

customizing vitals
https://sourceforge.net/p/openemr/discussion/202504/thread/a69d44f4/?limit=50#c805/4b33

Sent from sourceforge.net because you indicated interest in
OpenEMR / Discussion / OpenEMR Users

To unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net

–
Please be aware that e-mail communication can be intercepted in
transmission or misdirected. Please consider communicating any sensitive
information by telephone. The information contained in this message may be
privileged and confidential. If you are NOT the intended recipient, please
notify the sender immediately with a copy to hipaa-security@mrsb-ltd.com and
destroy this message.