Thoughts on providing better discrete data in VistA/CPRS with bi-directional data objects.

Kevin Toppenberg

unread,

Dec 9, 2015, 6:42:11 PM12/9/15

to Hardhats

In standard (vanilla) CPRS, a user can define a template for use in making notes. And these templates can make use of data objects. For example:

Patient: |PATIENT NAME|

Subjective

Objective

Assessment

Plan

When the user selects the template for use, the data object |PATIENT NAME| is converted into relevant data for the patient, and we end up with something like this.

Patient: DOE,JOHN

Subjective

Objective

Assessment

Plan

This is nice, but quite limited. The comes from the server, but the only thing that is stored back to the database is the entire progress note. It is not at all structured, and any opportunity to capture discrete data is lost. In contrast, the EHR at my hospital provides blocks to be placed in note template that actually capture the data.

The picture above is an Edit-Mode view of the data. Here I have defined an area to specify "diet", and it has multiple elements that can be selected for it. And this data is stored behind the scenes as structured data.

The picture above is a snipet from View-mode display of the data. Notice that only the items selected are shown. And until the note is signed, I can change back and forth between these two views.

I think CPRS and patients would benefit from the ability to capture discrete data from inside progress notes.

The closest that CPRS currently has, at least that I can think of, is reminder dialogs that set up health factors. Health factors are data storage items that allow one, for example, to specify that MAMMOGRAM DONE is true as of 1/23/15 at VA SPRINGFIELD. But these are limited in what they can store and are awkward to use (one has to leave progress note editing and launch a different dialog etc.)

----------

So here are my initial thoughts on a solution for this. It will require a modified CPRS, building on changes already put into TMG-CPRS, which uses a TWebBrowser to display and edit. For example in the image below.

Since I am already using HTML, then why not use HTML's ability to support controls? For example: http://www.w3schools.com/html/tryit.asp?filename=tryhtml_input_radio shows the simple HTML for creating a radio-button. I thought about this a few years ago, but gave it up, because the actual value of which button is selected is available primarily to javascript environment running in the browser (internet explorer in this case), and not available to my Delphi pascal that runs CPRS. But recently I realized a way around this problem: I use javascript to store the state of the switches etc in the DOM (the data structure making up the web page), and then I pull the entire DOM out, just as I previously did for saving the HTML-note.

Below I show a test form I added to our development version of TMG-CPRS. I start with very basic pseudo-HTML, that later can be entered by users or CACS

<p>

<CHECKBOX id="1">Do you like Apples?</CHECKBOX><BR>

<CHECKBOX id="2" checked>Do you like Grapes?</CHECKBOX><BR>

<CHECKBOX id="3">Do you like Strawberries?</CHECKBOX><BR>

<CHECKBOX id="4">Do you like Grapes?</CHECKBOX><BR>

<EDITBOX id="5" size="15" label="First Name: ">Initial Text</EDITBOX><BR>

<EDITBOX id="6" size="35" label="Last Name: ">Initial Text</EDITBOX><BR>

<WPBOX id="7">Bunch of text here</WPBOX>

</p>

Internally, I turn this into initial HTML that I can pass to the web browser.

<!DOCTYPE html>

<html>

<body>

<style>

p.inset {

border-style: inset;

border-width: 2px;

height: 100px;

background-color: #e5faff;

}

</style>

<p>

<input id="1" value=false type="checkbox" onclick="handleClick(this)" >Do you like Apples?</input><BR>

<input id="2" checked value=true type="checkbox" onclick="handleClick(this)" >Do you like Grapes?</input><BR>

<input id="3" value=false type="checkbox" onclick="handleClick(this)" >Do you like Strawberries?</input><BR>

<input id="4" value=false type="checkbox" onclick="handleClick(this)" >Do you like Grapes?</input><BR>

First Name: <input id="5" size="15" type="text" value="Initial Text" ></input><BR>

Last Name: <input id="6" size="35" type="text" value="Initial Text" ></input><BR>

<p id="7" class="inset" contenteditable="true" >Bunch of text here</p>

</p>

function handleClick(cb)

{

cb.setAttribute("value", cb.checked)

}

</script>

</body>

</html>

Here is an image of the data that I enter into the HTML page.

And here is the data pulled back from the browser, ready for use in CPRS

I have more to say about this, regarding the needed back-end changes needed to keep track of the structured data, but I think I will stop here for today.

Any feedback, good or bad?

Thanks

Kevin

Rafael Richards

unread,

Dec 9, 2015, 8:04:28 PM12/9/15

to Hardhats

Excellent direction you're heading.

Structured data inside HTML pages? Why not use the standard RDFa or JSON-LD markup? No "VISTA-special" markup.

Rafael

Sam Habiel

unread,

Dec 9, 2015, 11:21:37 PM12/9/15

to hard...@googlegroups.com

I really like the concept; but I am not sold on the approach.

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sam Habiel, Pharm.D.
VISTA Expertise Network

Kevin Toppenberg

unread,

Dec 10, 2015, 8:04:34 AM12/10/15

to Hardhats

The reason for the VistA markup would be that it is not just a matter of having the web browser display it. It would also have to be configured so that user-changes would be written back to the database.

I am open to suggestions. Can you tell me more about REF or JSON-LD>

Kevin

Kevin Toppenberg

unread,

Dec 10, 2015, 8:05:16 AM12/10/15

to Hardhats

Can you tell me what concerns you about the approach?

Kevin

To unsubscribe, send email to Hardhats+unsubscribe@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Sam Habiel

unread,

Dec 10, 2015, 11:56:43 PM12/10/15

to hard...@googlegroups.com

Not elegant; that's all. But I don't have an alternative yet.

To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Sam Habiel, Pharm.D.
VISTA Expertise Network

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

David Whitten

unread,

Dec 11, 2015, 5:55:58 PM12/11/15

to Hard Hats Mailing List

JSON-LD (JavaScript Object Notation - Linked Data) is a way of tying the

definition for JSON data with the data itself.

Much like data in VistA is known to have a file and field number that allows

you to access the data definition for the data.

RDF (Resource Description Framework) is a (wordy) representation of data

in a form to allow drawing conclusions about it (inference) and allowing the

definition of the data to be available for that use.

David Whitten

Kevin Toppenberg

unread,

Dec 12, 2015, 3:34:30 PM12/12/15

to Hardhats

Thanks Dave,

So I guess Rafael was indicating that the structured data could be stored in the HTML itself. With the info Dave has provided, I think he was trying to say the structure of the data that would be stored in the HTML.

I have a different idea. We currently do store data in notes in the form of tagged text. And we can get it back out, but it is always a hassle of parsing the text each time. I want to put it out and store it in an easily accessible Fileman file.

I'm going to make a separate post about my further ideas.

Kevin

To unsubscribe, send email to Hardhats+unsubscribe@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Sam Habiel, Pharm.D.
VISTA Expertise Network

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+unsubscribe@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Kevin Toppenberg

unread,

Dec 12, 2015, 7:34:45 PM12/12/15

to Hardhats

PART II

In my first post, I showed how a web browser could be used to present a GUI with rich controls (e.g. check boxes, edit fields, WP fields etc) in them. And this data can then be pulled out of the HTML source code. But user interface is just one piece, and not sufficient for full working system. I want to further flesh this out.

First, I want to show graphics showing the current situation with standard VistA.

Above we have a simple template containing a TIU TEXT OBJECT (in this case |PATIENT NAME|) that the server resolves with patient data and the resulting text is put into the clinical note.

But current CPRS supports templates that can be dialogs, providing more functionality than the simple example above...

Above shows the definition of a template that is more complex, including fields for user input...

Above shows the standard way that VA fields are defined. This one is an edit box for entering short answers into. Notice that this VA control just describes details about what a user is shown in the GUI. The same control may be used over an over for various questions that are not related to each other at all. But comparing these VA input fields to the interface from the interface in my local hospital (shown again below) shows that VA controls lower-level than would be needed to capture a data object storing, for example, diet as below. The diet control below is essentially a collection of 15 check boxes, so I would need to figure a way out to implement this.

Time to display the dialog...

Above shows the dialog that will pop up in CPRS when the template is selected, providing a GUI where the user can enter information. Notice that information can only be entered using the various controls. The labels and surrounding text is static and unchangeable here.

And finally the image above shows that all the text is dropped into the clinical note as unstructured text. All information related to the field control that was used to capture the control is lost.

Summary:

Above summarizes the flow from template definition, to data entry to data view in traditional VistA.

---------------------------------------------

And now to move on to new ideas....

Above I show how the standard flow could be used with HTML. It would loose structured data, but the GUI would likely be slicker and easier on the eyes (and probably faster. CPRS templates are horrible and slow when have to assemble step by step as the user interacts with it.)

But I have a better idea of how to do this below...

And finally, above, I show a flow whereby discrete data is kept in a separate data model, and uses this to populate either an edit-mode view in HTML, or a display-only view in HTML. Then, when it comes time to save the note, the text (in HTML format) of the clinical note is saved normally. But at the same time, the object model is written back to the server as discrete data elements for future use.

How could I use this?

I currently store information in tagged-text tables, e.g. surgical history, family history, social history etc. When needed in the future, I scan back through prior notes for the table and use it to pull forward. It is always messy to parse through free-text notes, and takes more computational power than it would to simply get it from a Fileman file.
I could use this for problem tracking. I have written before about the difficulty of keeping tract of a given patients multitude of problems without having to address them every time, and also to not loose track of them on future appts. E.g. if I haven't talked about a patient's gout in some time, how do I remember it? The solution will need to include the problem list, but I am still working on making this more usable. And when I do address their gout, it would be nice to be able to see a threaded view of the prior discussions of the problem, so I don't have to start from scratch every time.
I would ideally like to integrate this system with the clinical reminder system and ordering system, such that everything that needs to be done could be done directly IN the note rather than having to have launch dialog boxes that then dump results into the note.
Any other use of discrete data that might come up in the future. There are times when health factors can't capture everything that might be needed for reporting quality statistics.

Anyway, I have made these graphics to try to get this all straight in my mind. It looks a bit daunting right now, and I'm not 100% sure I want to go forward with this. I'm trying to figure out the most generic way it can be done, so that I could build on it later. And also I need to figure out how to integrate it with current VA template fields etc.

Thanks for listening. Feedback always appreciated.

Kevin

David Whitten

unread,

Dec 14, 2015, 9:18:24 AM12/14/15

to Hardhats,

Kevin,

you may want to store information in a similar format to the RESPONSES field #4.5 in the ORDER File #100.

It looks like a general way to store tagged data.

David

Kevin Toppenberg

unread,

Dec 14, 2015, 3:01:49 PM12/14/15

to Hardhats

Dave,

Thanks for the suggestion. I'll check it out.

Kevin

Kevin Toppenberg

unread,

May 10, 2016, 10:07:01 AM5/10/16

to Hardhats

OK. I have been working on this issue of bi-directional data objects for quite some time now, and I want to give an update.

First, I coded to allow templates, with standard VA controls to be view-able in an HTML document. For example here is a standard TIU dialog we use for for documenting medication administration...

And here is this same template interpreted and put into a web browser instead. This might look easy, but was quite difficult, and involved steps outlined in my original post.

In the above example, there was just one dialog in one HTML display window (a TWebBrowser). I wanted to be able to have multiple such controls inserted into a progress note or other TIU document. So I then encapsulated each object and made them each unique, and then inserted them into the TWebBrowser that TMG-CPRS uses to display formatted notes. The result looks like this. I will change the template dialog here to one involving a date input control.

The above image is while the document is being edited. Below is when the document is in view mode.

And the user can change back and forth between edit and view modes until the document is signed, just as would be expected.

In the HTML, the data is stored as follows. Discussion below:

------------------------------------------------------------------------------------------------------------------

<BODY contentEditable=false><PRE> LOCAL TITLE: ACUTE MEDICAL ISSUE VISIT

STANDARD TITLE: E & M CLINICAL NOTE

DATE OF NOTE: MAY 10,2016@07:27 ENTRY DATE: MAY 10,2016@07:27:11

AUTHOR: TOPPENBERG,KEVIN S (MD)

URGENCY: STATUS: UNSIGNED

</PRE>

<HR>

<P>

<STYLE>

.tmgembeddeddlg {

BORDER-RIGHT: gray 1px solid;

BORDER-TOP: gray 1px solid;

BORDER-LEFT: gray 1px solid;

BORDER-BOTTOM: gray 1px solid

}

.tmgembeddeddlg_result {

BORDER-TOP-STYLE: none;

BORDER-RIGHT-STYLE: none;

BORDER-LEFT-STYLE: none;

BORDER-BOTTOM-STYLE: none

}

.tmghidden {

DISPLAY: none

}

</STYLE>

05/10/16  

<P>

<SPAN id=ctrl1_TMGDlg1

fmdtvalue="3160000"

value="2016"

DateMode="0"

DTMode="0"

onchange="handleOnChange_TMGDlg1(this)"

tmgtype="date"

dtformat="mmm d, yyyy">

<OPTION value=0 selected>-month-</OPTION>

<OPTION value=1>January</OPTION>

<OPTION value=2>February</OPTION>

--cut for brevity--

<OPTION value=12>December</OPTION>

</SELECT>

--cut for brevity--

</SELECT>

<BUTTON id=ctrl1_TMGDlg1-ClrBtn>Clear</BUTTON>

</SPAN><BR>

TEXT: <INPUT id=ctrl2_TMGDlg1 onchange=handleOnChange_TMGDlg1(this) size=40 value=2016 tmgtype="editbox"> <BR>

<BR>

</SPAN>

TEXT: <B><I>4/7/2016</B></I><BR>

<BR>

</SPAN>

{HTML_CTRL:ctrl1_TMGDlg1^TMG TEST DATE}<BR>

TEXT: {HTML_CTRL:ctrl2_TMGDlg1^TMG TEXT}<BR>

<BR>

</SPAN>

</SPAN></P>

--cut for brevity---

</SCRIPT>

<PRE>

</PRE></BODY>

------------------------------------------------------------------------------------------------------------------

First of all notice that the entire control is wrapped in
<SPAN contentEditable=false> .. </SPAN>

This keeps the user from being able to delete one part of the control but not another. It keeps it together.

Then notice that there are three contained spans inside this block.
<SPAN class="tmgembeddeddlg is for holding the HTML control that the user interacts with during edit mode.
<SPAN class=tmgembeddeddlg_result is for holding the external text that is shown during view mode
<SPAN class="tmgembeddeddlg_source is for holding the source code of the template, so that when editing is resumed (perhaps days later), that the control can be reconstructed. This is needed when converting the edit mode display into the view mode text.

To control which of the above spans is visible, I add or remove the 'tmghidden' name to the span's 'class' property.

To control how all this works in the page, there is javascript that is added. I have cut it out above because it can be lengthy.

--cut for brevity---

</SCRIPT>

And because the script is lengthy, I don't really want to have to store all that overhead for each note, which would take up disk storage with redundant code. I do this on the server side. The TIU package provides a hook for POST-SIGNATURE code. So I run some mumps code that can pull out the unneeded stuff after the note has been signed.

That's all for now. I will post again soon about user-supplied javascript code that can interact with the controls, and future plans.

As always, feedback is appreciated.

Kevin T

On Wednesday, December 9, 2015 at 6:42:11 PM UTC-5, Kevin Toppenberg wrote:

Kevin Toppenberg

unread,

May 10, 2016, 10:51:30 AM5/10/16

to Hardhats

OK. Next I want to talk about user-supplied javascript in TIU TEMPLATES.

First a discussion of security. The javascript that is run in the TWebBrowser is in a sandbox. It can't access anything outside the DOM. But it can theoretically call out to the internet. So, because some mischief might come out of this, I am going to restrict the ability to save templates with the <SCRIPT> tag to users with a custom security key. This would allow only trusted users to make them.

Having said that, here is the definition of the TIU TEMPLATE:

{FLD:TMG TEST DATE}

Text: {FLD:TMG TEXT}

function handleOnChange(elem) {

var dlgHandle = getDlgHandle(elem);

var CtrlNum = getCtrlNum(elem);

if (CtrlNum == 1) {

var DateVal = getCtrlVal(dlgHandle, 1);

setCtrlVal(dlgHandle, 2, DateVal);

} else if (CtrlNum == 2) {

var newVal = getCtrlVal(dlgHandle, 2);

setCtrlVal(dlgHandle, 1, newVal);

}

</SCRIPT>

The area shaded in green is how traditional VA templates are defined. The {FLD:xxx} is how one inserts controls into a dialog. The area shaded in yellow is the part I am adding. And the key line is function handleOnChange(elem) This function, if the user has supplied it, will be called anytime the onchange event occurs for the dialog controls. This then gives the user a chance to do what every they want, for example calculating formulas. Examples of that later...

Each dialog has a handle. So if a given document has 10 inserted inline dialogs, then each one would have a separate handle. This handle is used when reading and writing to the controls. It is obtained with this code:

var dlgHandle = getDlgHandle(elem)

Before the script can do any calculations based on user input, it must get get value from the control. This is done like this:

var DateVal = getCtrlVal(dlgHandle, 1);
This allows the script to obtain the value of the 1st control.

In the above script, I am making it such that if either control is changed, it sets the value of the other one. So the next needed function is the ability to set a control value. This is done with this code

setCtrlVal(dlgHandle, 2, DateVal);

This says to set the value of the 2nd control with the value stored in the variable DateVal.

Here is another example:

Number 1:{FLD:NUM 0-10}

Number 2:{FLD:NUM 0-10}

Sum: {FLD:00 EDIT BOX 12}

Mult: {FLD:00 EDIT BOX 12}

function handleOnChange(elem) {

var dlgHandle = getDlgHandle(elem); //intrinsic Fn

DoMath(dlgHandle);

}

function DoMath(dlgHandle) {

//getCtrlVal() is an 'intrinsic' function in CPRS

var Ctrl1 = getCtrlVal(dlgHandle, 1); //get val 1st ctrl

var Ctrl2 = getCtrlVal(dlgHandle, 2); //get val 2nd ctrl

var N1 = parseInt(Ctrl1);

var N2 = parseInt(Ctrl2);

COMMON_DoSum(dlgHandle, N1, N2);

COMMON_DoMult(dlgHandle, N1, N2);

}

function COMMON_DoSum(dlgHandle, N1, N2) {

//Because of COMMON_ prefix, all instances of dlg will use this fn

var Result = N1+ N2;

//setCtrlVal() is an 'intrinsic' function in CPRS

setCtrlVal(dlgHandle, 3, Result); //set val 3rd ctrl

}

function COMMON_DoMult(dlgHandle, N1, N2) {

var Result = N1 * N2;

setCtrlVal(dlgHandle, 4, Result);

//set val 3rd ctrl

}

</SCRIPT>

This example takes the numbers input by the user in the 1st and 2nd controls. It multiplies them and adds them together, and puts the results into the 3rd and 4th controls.

All of this is currently working.

Got to run. More to follow.

Kevin

On Wednesday, December 9, 2015 at 6:42:11 PM UTC-5, Kevin Toppenberg wrote:

Kevin Toppenberg

unread,

May 10, 2016, 12:07:43 PM5/10/16

to Hardhats

Next, I want to talk about storing data back to the server, in discrete format. This was my original intent of the project. I was initially struggling with the concept of somehow storing the entire dialog definition as corollary to a data dictionary entry for a file. But I since decided that this will end up storing unwanted cruft, so I will just let the template writer decide what should be stored. So here are my plans... to be implemented.

I am going to implement this by providing another javascript function for script writers to use:

storeDBVal(dlgHandle, Key,Value, type);

This will store simple key<--> value pairs. E.g.

storeDBVal(dlgHandle, 'TMG_num_of_children', 5, 'number');

would store

TMG_num_of_children = 5 for a given date.

This data will be stored in the HTML of the document using a de-novo <DBSTORE> tag as follows, to be later pulled out during the POST-SIGNATURE server-side mumps code and put into a formal Fileman file.

--cut for brevity--

</SPAN>

--cut for brevity--

</SPAN>

--cut for brevity--

</SPAN>

</SPAN>

</SPAN></P>

To give the script writer complete control of what gets stored and not stored, I will also include a function to undue the <DBSTORE> tag, as follows

unstoreDBVal(dlgHandle, 'TMG_num_of_children');

I can think of situations where this will be needed, but won't elaborate here.

This is the Fileman file I will put this data into after processing.

File: TMG PATIENT DISCRETE DATA Branch: 1

REF NODE;PIECE FLD NUM FIELD NAME

===============================================================================

1 0;1 .01 PATIENT <-Pntr [RP2']

2 0;2 .02 TIU DOCUMENT <-Pntr [P8925']

3 0;3 .03 DATE [D]

1;0 1 DISCRETE DATA <-Mult [22729.01S]

4 -0;1 .01 -DATA TYPE [S]

5 -0;2 .02 -NAME [FJ64]

6 -1;1 1 -TEXT [FJ250]

7 -2;1 2 -DATE [D]

8 -3;1 3 -NUMBER [NJ18,8]

-4;0 4 -WP TEXT <-WP [22729.14]

9 --0;1 .01 --WP TEXT [Wx]

<> <> <>

===============================================================================

<> 'n',I=FldDD DA=Data F=Find G=Goto N=Node P=Pointer VGL=VGL ?=Help

Select:

Kevin

===================================================================================

Reply all

Reply to author

Forward