Persistent WIP
From DOC
NOTE: This feature is under development.
Persistent WIP provides a single document within a given placeholder such as patient. In most cases, the document is associated with a user, technically, account user. In other words, documents being edited cannot be shared between accounts. A persistent WIP document is opened automatically and remains visible to the user when the placeholder is open.
A placeholder is opened by opening a particular page template, and for the remainder of this description, patient will be assumed to be the placeholder. So the page template for a patient is by default five/patient.xhtml. This template will open the menu for this patient and typically open a summary or other page related to the patient. The user will not need to open the WIP document: It will be created if needed and/or opened if it already exists for the account user.
Contents |
WIP Pane Visual
The page five/patient.xhtml will be changed to create a new WIP pane at the right of the patient's display that will hold the Patient WIP document. This new pane will be called five/patientWIP.xhtml and it will be responsible for opening and displaying the document. The idea being that the WIP document will be visible no matter which menu within the patient is selected. Of course the WIP for that patient will not be visible when a different patient (or non-patient) placeholder is currently in focus.
+-----+--------+
| tab | Pat 1 |
+-----+ +--------------------+
| Wip Bar |
+-----------------------------------+
| menu menu menu |
+--------------------------+--------+
| patient details | New |
| | WIP |
| | Pane |
| | |
| | |
+--------------------------+--------+
Tolven API
A new EJB entity and DB table will be created in org.tolven.app.entity called accountUserWIP which will contain an ID, a reference to the account user, and a reference to the WIP document. A new method called findCreateWIP() in a new session bean called org.tolven.app.bean.PlaceholderWIP If a document does not exist, one should be created automatically.
Security
If the user does not have access to the WIP display, then the WIP is not displayed and the user is not allowed to add items to the WIP document.
Document Structure
The WIP document is a TRIM document, following the HL7 V3 CDA structure. For example, the top-level act is DOCCLIN. There are then sections under that and then various types of acts within each section.
A new Faces Backing bean supports access to this document. The bean should be called WIPAction (context variable for this request-scope bean is wip). It can contain various methods to edit and extract content from the underlying document.
Add Act Function
When a trim is selected from a trim menu, such as a list of observations, the action will call a method in WIPAction bean that will add the top-level act from the selected bean to the list of acts in the current WIP document for that placeholder (patient). The add act function will also popup an act detail dialog for the newly added act, see below.
Edit Act Function
When an existing act on one of the display relating the the patient is dragged to the WIP document, the underlying placeholder becomes the template from which a new act is created. This is more complicated that it may look. If the underlying document is a TRIM and the placeholder contains a path into the TRIM document, then the act itself can be copied directly to the WIP document.
However, in some cases, the source document will contain non-TRIM content in which case, only the placeholder can be used. For example, let's say that a diagnosis from the patient was created via CCR (not TRIM) and nevertheless created a diagnosis placeholder (under the patient placeholder). This requires two things to occur:
- An appropriate TRIM must be found to represent the edited diagnosis
- The TRIM must contain EL that pulls previous value from the existing placeholder
As a convention, the variable source is used to reference the existing placeholder from which values can be harvested.
<effectiveTime>
<TS>#{TS(source.effectiveTime)}</TS>
</effectiveTime>
<observation>
<value>
<PQ>
<value>#{source.value}</value>
<units>#{source.units}</units>
</PQ>
</value>
</observation>
TRIM Insertion Semantics
The HL7 RIM CDA document structure plays a critical role in determining how an act is added into an existing WIP document. In effect, the source TRIM will contain a fragment of the target document structure. For example, consider the following abbreviated weight assessment TRIM:
<trim ...>
<act classCode="DOCCLIN" moodCode="EVN">
<relationship name="component" type="COMP" direction="OUT">
<act classCode="DOCBODY" >
<relationship name="component" type="COMP" direction="OUT">
<act classCode="DOCSECT" moodCode="EVN">
<title><ST>Objective</ST></title>
<relationship name="entry" type="COMP" direction="OUT">
<act classCode="OBS" moodCode="EVN">
<title><ST>Weight</ST></title>
...
</act>
</relationship>
</act>
</relationship>
</act>
</relationship>
</act>
</trim>
The document structure
Detail Dialog
This popup is displayed when the user double clicks an item in the Document WIP pane or when a new or edited item is dropped. In all cases, the popup is a mechanism for editing one line-item in the document WIP. The term sub-tree is used here to mean all of the elements at and below the act which is under the section.
<trim ...>
...
<act classCode="DOCCLIN" moodCode="EVN">
<title>
<ST>My Document</ST>
</title>
<relationship>
<act classCode="DOCSECT" modeCode="EVN">
<title>
<ST>My Document</ST>
</title>
<relationship>
<act classCode="OBS" moodCode="EVN">
<code>
...
...
The detail popup contains the following elements:
+--------------------------+ | Act title | +--------------------------+ | | | Wizard details | | *Errors | +--------------------------+ | Prev Cancel Save Next | +--------------------------+
- Act title - from the root act of the subtree being edited.
- Prev - save this and move to the previous act, if any. Should be disabled, dimmed, if there is no previous act.
- Cancel - Close this dialog and discard changes made during this interaction
- Save - close this dialog and save the changes to the active WIP document.
- Next - Close this dialog, save changes, and open the next act in the WIP document. If no next act, then this button should be dimmed/disabled.
- Any errors detected in that act should be displayed on the dialog
TRIM State
When a change is made to the WIP document, the compute scanner should be called as usual. This will update any contents of the TRIM control by compute functions. Any change to the TRIM should also update the corresponding MenuDataVersion. This will cause the browser to notice a change and refresh the WIP document display.
One important feature when the computes are called via this new mechanism is that any validation errors are maintained in the TRIM itself rather than only in the page. Therefore, the WIP document can highlight entries with errors.
Validation
Each "slot" and overall act, role,entity, will now support integral error indications maintained by the compute scanner and displayed both by the detail dialog and the WIP display.
<act>
...
<compute ...>
...
</compute>
<error>Error text</error>
A trim is only submittable when there are no errors in the TRIM document. Therefore, the Submit button should be disabled if any exist in the TRIM. Further, each item in the WIP document list should be highlighted in red if there is an error within it and the rollover of that item should contain the text of the error.
