Contents
Overview
Form Development Requests fall under two classifications: Simple or Complex. Clinical Informatics are responsible for communicating with the requestor, identifying the form classification and creating the JIRA ticket. The Form Development Requests are then reviewed during intake and assigned directly to a developer or an analyst. The assigned developer or analyst is responsible for reviewing all the requirements gathers by Clinical Informatics and contacting the requestor if further clarification is needed prior to developing the Form. Once form development is complete, QA testing is required by a peer analyst or QA lead. Once testing has passed, follow regular CC process to have the Form deployed to Production.
Form Classifications Definitions
Simple Form (SF)
Definition: Form does not require HRIs (Health Record Index) to be linked to data fields. This means SF data is not searchable via Find Object Queries or able to be populated with specific fields entered from other forms. SF may have field auto-population of data available using Print Variables.
Workflow Requirements:
- Do not require a Requirements and Specification document (the auto-generated file in the Analysis subfolder should be deleted). In lieu of this, the original request should be saved into the Emails or Analysis subfolder,
- Do not need Tech Review by a developer
- Review by a peer analyst or quality assurance lead using the SF Standard TestCase to verify that the form conforms to our standards
Complex Form (CF)
If the form contains any custom macros, it is considered a complex form. They can range to having simple minor macros to having quite advance functionality. Complex forms follow the same work item workflow as all other CC requests.
Workflow Requirements:
- Requirements and Specification document (or form will not be rejected during CC approval process)
- Note: If it is a "Mid-Level" Complex Form, it will require reqs & specs however it can be fairly brief and simply filled in, stating that it is a simple form except for these additional requirements
- Tech Review by a developer
- Review by a peer analyst or quality assurance lead using the CF checklist to verify that the form conforms to our standards
Change Request
Workflow Diagram
Modify JIRA
When you are assigned a Form Development JIRA.
1. Ensure to updated the beginning of the JIRA with the following naming convention:
- New Form -
- Update Form -
- Remove Form -
2. Search for the form on the IH Marketplace. If the form does not exist on IH Marketplace proceed as usual. If the form is available, download the Jaffa file and import to Dev and customize the form if required otherwise proceed with usual steps for form development. For addition details refer to the article: Search for Form on IH Marketplace
3. Attach the pdf/ doc of the form requested to be built
4. Embed link to testrail test case that you created for form testing
5. When Form is ready for testing, change the status to QA ready and assign to QA Lead or Peer Analyst.
6. QA lead/ Peer Analyst to create Test Run in Testrail.
- Copy and Paste the Simple Form Template into your Change Control folder
- For Complex Forms, test cases will need to be created based on the respective specifications for design.
Analysis & Design Phase
Once Form Development request has been assigned to you. It is your responsibility to review all the requirements in the JIRA ticket and folder. The Simple Form Request - Analysis Checklist has been designed with all considerations in mind when working on developing a Simple Form. For complex forms, use the Complex Form Checklist. The checklists can be found in the Form Reference Guides and Checklist article.
For all Complex Form Request, a reqs and specs document is required. These two documents should be used to document all the changes that the requestor is looking to accomplish. Once complete, save it to the Analysis folder. This will be used by the QA tester once Development is complete.
Development Phase
Now that all the requirements have been documented. You can now begin developing the form. Please ensure that you are following the Form Development Standards.
If you need a refresher on how to do certain development pieces you can refer to this article for guidance.
If you require assistance from a developer, notify Harinder who will assign you a developer to work with.
QA Phase
When your form development is complete, run a preliminary test on your form to ensure it meets the Form Development Standards as this will be reviewed during QA Testing. When you are ready for QA Testing to begin, place the Form into the Form Category folder identified during the Analysis Phase and export/ save it to the Dev folder. You will then use this jaffa to import the form into the dedicated Test Environment.
Preparing for QA Testing
- If not already there, in the CDO Explorer window, move by dragging the item to the folder category that the form should live.
- Select the form in the Contents panel and then click on the Export form icon
- Save it in the work item’s Dev folder with an appropriate name (common convention is starting with the JIRA ID). It will automatically save it as a jaffa file type (.jfa)
- Log into TEST environment using your Sys Admin user account
- Click Organisation > Import & Export > Import Jaffa File…
- Select the jfa file that was just created
- Click Start in the Jaffa File Import window
- A new window with the import log will show. Once it’s done, you can close this window
- If you open up the CDO Explorer window, the form should be found under the same folder structure that it was exported from in DEV
- Contact a peer analyst/QA lead to perform the SF Standard TestCases on this
Documenting in the QA phase
Create the test cases in TestRail by copying the Standard Simpleform Testcase into new testcase and assign the JIRA to QA lead or Peer Analyst to review/test your form in the dedicated Test Env. QA lead or Peer Analyst may ask you clarification questions during this phase, if deemed necessary. Otherwise, they will notify you once form testing has passed.
Note: "mid-level" complex forms will also have the checklist filled in however we should add steps for the additional requests that would make it no longer a simple form (should mirror the requirements listed in the reqs & specs
Production Ready: Submitting and Managing your CCs
Now that testing has been completed. Add a comment in the JIRA with the link to passed Test Run. Refer here for instructions. Ensure the Sys Config document is completed (Note: Sys Config can be worked on at any point of form development) and submit your CC following the Profile EMR Workflow Guide.
Closing Request Activities
You will be notified once your Form Development Request has been deployed to Production. At this time, you will go into Production and using the T Prac Client, you will validate that the Form has been deployed and functions the way you developed it. Once validation is complete, you can send the Approved/Completed CC to VCH EMR Team as per Profile EMR Workflow Guide.