Notifications
Clear all
Topic starter
I am building a form where I need to capture repeated obs terms(basically serial assessment type values) for the same visit, so that when you look at the flow sheet in minutes, you will be able to see the different values, by the time recorded. (I have referenced a flow sheet that I have built within the form and would preferably like the values to populate (refresh within the flowsheet itself, as the values are committed. Save a user an additional click to get to the flowsheet on a different tab, or elsewhere in the system)
I can set the values within the form, however, I’m having a difficult time getting the obs terms to record at the different times they are committed.
What I need to be able to do is:
- Have the values placed, then committed.
- Have the values cleared out of the form
- Once the new values are put in, have them captured with the same obs terms at the different time.
Any information offered will be appreciated!
Posted : April 30, 2018 1:06 am
What you are asking for is deprecated functionality and most probably will not return under the current architecture (maybe NorthStar?).
OBSNOW accepts an undocumented 4th argument for dates OTHER than the date of the update. Formerly it also worked for 'current' observations which allowed the user to store serial observations (and it was very useful). Unfortunately, around 2006 or 2007, GE removed the functionality due to misuse that resulted in unintentional database bloating. NOTE: This can still be an issue, so if you use the time argument for values dated differently from the udpate, ensure it is stored only once, especially after reopening the update from being on hold. You can verify this by reviewing a MEL trace and reviewing the clinical list changes.
The best you can hope for is to create a workflow where users store the data in a single obsterm and subsequent records are appended to the existing data. Ideally, you would include the time stamp as part of the data stored which is really less than ideal as it consumes precious characters in the 2K limit.
Example:
In an action button set to runprocess, you would use something like this:
if OBSNOW("OBSTERMNAME") <> "" then
OBSNOW("OBSTERMNAME",OBSNOW("OBSTERMNAME") + HRET + TIMESTAMP() + ": " + DOCUMENT.VARIABLENAME)
else
OBSNOW("OBSTERMNAME",TIMESTAMP() + ": " + DOCUMENT.VARIABLENAME)
endif
Posted : April 30, 2018 4:29 am
I agree with Lee's post and appreciate him sharing the history. Something else you might want to consider is storing the parameters (timestamp and obs value) in a JSON formatted string (key/value pairs) inside the OBS term. For example, let's say you were recording heart rate every 15 minutes over the course of an hour. The data collected might look like:
04/30/2018 16:00 - 68bpm
04/30/2018 16:15 - 82bpm
04/30/2018 16:30 - 122bpm
04/30/2018 16:45 - 130bpm
The JSON formatted string would look like:
[{"timestamp": "04/30/2018 16:00","bloodPressure":"68bpm"},{"timestamp": "04/30/2018 16:15","bloodPressure":"82bpm"},{"timestamp": "04/30/2018 16:30","bloodPressure":"122bpm"},{"timestamp": "04/30/2018 16:45","bloodPressure":"130bpm"}]
You could even store more parameters if there was a contextual reason for doing so (e.g. when conducting a stress test); you would just need to be mindful of the 2000 character limit.
Obviously, storing data in this manner would require you to pass the obs term to a text translation function in order for it to appear nicely in the document, but you would only have to write this function once and it could accommodate any other serialized data you might collect. There are several other advantages of storing data in this manner. It is much easier to develop and maintain functions that will display this data on a form and apply styling because you can differentiate between the data structure and the values. It is also easier to parse out specific parameters, perform calculations, compare with previous values, share data with other applications, etc. The decision to use this method really just depends on how you might want to display or use the data down the road. If the serialized data is being captured for something episodic, then perhaps it wouldn't make sense to use this method. When in doubt, I tend to use this strategy.
Posted : April 30, 2018 8:51 am
