Summary
This article covers the patient management report.
Table of Contents
- Status Properties
- Status Terms
- Creating Status Expressions
- Expressions Defined At a Status# Level
- Relative MetaData
- Expressions Defined At A Relative Level
Design | System
A Patient Management Report is a configurable application specific report used to evaluate each patient’s status relative to the completion of each study visit in a study calendar. The Patient Management Report will be named based on the recordName setting on the Application Setup worksheet in the DataArchitect, for example, this report could be called Subject Management Report.
A study specific Patient Management Report can be configured by incorporating visit evaluation ‘statuses’ based on pre-defined criteria associated with Visit Schedule ‘relatives’ in the App Properties worksheet. Each status can be configured to represent different aspects or stages of completion relative to the study schedule. By creating status relationships for each relative an entire Patient Management Report can be created.
It is highly suggested that you review the relatives information provided in the Visit Schedule Guide to assist you in building the properties to create this report.A status property is identified in the Name column (column A) of the Properties Worksheet. Each identified relative status is defined in the Value column (column B). The following represent the properties used to create a Patient Management Report:
Status Properties
For all metadata statuses that will be referenced in the report the property must be set to ‘true’. Lists of the properties are:
| Property | Definition | Options |
|---|---|---|
| answerStatus | Defines the Answer Status metadata | completed blank inProgress |
| violationStatus | Defines the Alert Status metadata | clean alertClosedOverride alertClosed alertOpenOverride violation |
| queryStatus | Defines the Query Status metadata | clean openQuery |
| validationStatus | Defines the Source Doc Verified metadata | yes no |
| signedStatus | Defines the Signed by PI metadata | yes no |
| freezeStatus | Defines the Freeze/Frozen Status metadata | frozen partiallyFrozen unfrozen |
| lockStatus | Defines the Locked Status metadata | locked partiallyLocked open |
| dataReviewStatus | Defines the Data Review Status metadata | reviewed notReviewed |
relative#Question
Defines the relationship to an absolute property in an application. The relative question shall be added to identify the record in the report.
- PrimaryName
- SecondaryName
- ToolName
statusName#
Defines the display text associated with a status. Common statusNames are as follows however these can be anything the client would like:
- Off Study
- Signed
- Reviewed
- Not Done
- Qualified
- Problem
statusColor#
Defines the background and text colors of the report cells. Values are comma delimited (the first color is the background, the second is the text). The color options are Aqua, Black, Blue, Fuchsia, Gray, Green, Lime, Maroon, Navy, Olive, Purple, Red, Silver, Teal, White, and Yellow.
Common examples of color options:
- Lime,Black
- Blue,White
- Yellow,Black
- Green,White
- Red,White
status#
Defines the functionality of each status.
- Each status can be further defined at a ‘relative’ level (visit level)
- There is no limit to the number of statuses in a report
- The # represents the priority level of the evaluation criteria
- The lowest number takes priority
- All reports must have a status0
Status Terms
Each status will be defined using the expression language. Status expressions will commonly evaluate the metadata statuses associated with each patient’s visit. The following are examples of common status evaluation expressions:
| Type | Value |
|---|---|
| PI Signature | signedStatus == ‘yes’ |
| Lock Status | lockStatus == ‘locked’ |
| Freeze Status | freezeStatus == ‘frozen’ |
| SDV Status | validationStatus == ‘yes’ |
| Alert Status | violationStatus == ‘clean’ violationStatus == ‘violation’ violationStatus == ‘alertOpenOverride’ |
| Query Status | queryStatus == ‘clean’ |
| Data Review Status | dataReviewStatus==’reviewed’ |
| Container Evaluation | CHILDFORMS_ANSWERSTATUS_NOTBLANK=true |
Note: the CHILDFORMS only has one equal sign (=) and not two (==) and it does not have ” around the true variables, like the other expressions.Creating Status Expressions
Each status will be defined at a report level with a status# definition or at a ‘relative’ level in direct association with a Visit Schedule relative. If a status is defined at the status# definition it will not be defined at a relative level. If a status needs to be defined at a relative level, it will be represented by ‘false’ on the status# definition level.
Statuses may need to be defined at a relative level if there are variations of the possible status based on specific form content such as a specific date reference.
Expressions Defined At a Status# Level
The following are examples of common status# defined expressions:
| Status | Expression | Intent |
|---|---|---|
| PI Signature | signedStatus == ‘yes’ AND validationStatus == ‘yes’ AND queryStatus == ‘clean’ AND freezeStatus == ‘frozen’ | This expression verifies the container is signed by the Investigator, the forms are SDV and Frozen and that there are no open queries. |
| Verified | validationStatus == ‘yes’ AND queryStatus == ‘clean’ AND freezeStatus == ‘frozen’ | This expression verifies that the forms are SDV and frozen and that there are no open queries. |
| Problem | violationStatus == ‘violation’ OR violationStatus == ‘alertOpenOverride’ OR queryStatus != ‘clean’ | This expression verifies that there are no alerts (with or without a Reason for Override) and there are no open queries. |
Note for CHILDFORMS the AND/OR are not used, a comma is.
These expressions will be defined at an overall status level. These properties will appear as follows in the App Properties worksheet:
| Name | Value |
|---|---|
| statusName0 | Problem |
| statusColor0 | Red,White |
| status0 | violationStatus == ‘violation’ OR violationStatus == ‘alertOpenOverride’ OR queryStatus != ‘clean’ |
| statusName1 | Signed |
| statusColor1 | Lime,Black |
| status1 | signedStatus == ‘yes’ AND validationStatus == ‘yes’ AND queryStatus == ‘clean’ AND freezeStatus == ‘frozen’ |
| statusName2 | Reviewed |
| statusColor2 | Blue,White |
| status2 | validationStatus == ‘yes’ AND queryStatus == ‘clean’ AND freezeStatus == ‘frozen’ |
| statusName3 | Not Done |
| statusColor3 | Yellow,Black |
| status3 | false |
| statusName4 | Qualified |
| statusColor4 | Green,White |
| status4 | false |
Note: status3 and status4 will need to be defined at each relative level status because they are defined false at the status level.Relative MetaData
For each relative defined a relative#MetaData status must be defined to identify where the statuses should be evaluated.
relative#MetaData
Defines the primary point of orientation for the status. This must be an absolute path to a form summary from the application.
Expressions Defined At A Relative Level
The following are examples of common ‘relative’ status related expressions:
| Status | Expression | Intent |
|---|---|---|
| Qualified/Complete | #stage1.screening.demo.demodt != ” AND violationStatus != ‘violation’, violationStatus != ‘alertOpenOverride’, CHILDFORMS_ANSWERSTATUS_NOTBLANK = true, queryStatus == ‘clean’ | This expression evaluates the visit date of the demographics form. This date field must not be empty for the visit to be considered Qualified/Complete. It also checks to verify that there are no alerts without a reason for override, that there are no open queries and that the child form statuses are not blank (they must be in progress or completed). |
| Not Done | #stage1.screening.demo.demodt == ” AND #stage1.screening.demo.notdone == ‘yes’ | This expression verifies that the visit date of the demographics form is blank and that the not done question is answered yes. |
These expressions will be integrated into the visit schedule relatives and will appear as follows:
| Name | Value |
|---|---|
| relative3 | #stage1.screening.demo.demodt |
| relative3Name | Screening |
| relative3Baseline | #stage1.screening.demo.demodt |
| relative3MetaData | #stage1.screening.demo |
| relative3Status3 | #stage1.screening.demo.demodt == ” AND #stage1.screening.demo.notdone == ‘yes’ |
| relative3Status4 | #stage1.screening.demo.demodt != ” AND violationStatus != ‘violation’, violationStatus != ‘alertOpenOverride’, CHILDFORMS_ANSWERSTATUS_NOTBLANK = true, queryStatus == ‘clean’ |
Need more help?
Please visit the Fountayn Contact Information page.