Eforms
From CaisisWiki
Translations: italiano
Creating Eforms
1. Add the Xml file that defines your eform components to the “Eforms” folder of the appropriate disease module.
The following example would create an eform with one section, and two forms within that section: medications and lab tests. The interface would allow the entry of three medication records and one lab tests record. The letter notations (i.e. (A) ) are not part of the eform, but references to explain each section in more detail below.
<?xml version="1.0" encoding="utf-8" ?>
<eform name="GU Pros FU" displayName="GU Prostate Follow Up">(A)
<eformSection name="Presenting Details">(B)
<eformItem displayName="Meds" controlName="Medications"></eformItem>(C)
<eformItem displayName="PSA Lab Test"controlName="LabTestPSA"></eformItem>
</eformSection>
<Medications RecordId='1'>(D)
<Medication NotNull="True"></Medication>(E)
<MedDose></MedDose>
<MedUnits></MedUnits>
<MedSchedule></MedSchedule>
</Medications>
<Medications RecordId='2'>
<Medication NotNull="True"></Medication>
<MedDose></MedDose>
<MedUnits></MedUnits>
<MedSchedule></MedSchedule>
</Medications>
<Medications RecordId='3'>
<Medication NotNull="True"></Medication>
<MedDose></MedDose>
<MedUnits></MedUnits>
<MedSchedule></MedSchedule>
</Medications>
<LabTests>(F)
<LabDate></LabDate>
<LabDateText></LabDateText>
<LabTest NotNull="True"></LabTest>
<LabResult></LabResult>
<LabUnits></LabUnits>
<LabQuality></LabQuality>
</LabTests>
</eform>
(A) The eform name=”” attribute must be the same as the physical file name, but can contain spaces. For example, if the file name is GUProsFU.xml then the attribute must be in the format name=”GU Pros FU”.
The value of the displayName=”” attribute will reflect the visible title of the eform on the interface.
(B) eformSection is the group of forms that will appear on the interface together. The value of name=”” attribute will reflect the title of the group that appears in the left hand navigation of the eform.
(C) The child nodes of eformSection, eformItems are the forms that will be embedded in that section. The value of the displayName=”” attribute will display under the section in the left hand navigation. The value of the controlName=”” attribute is important. It is the name of the physical .ascx file to appear in this section of the eform. It must match exactly the name of an .ascx control that is in any of the Modules/SomeDisease/Eforms folders. For example, in the above example controlName=”LabTestPSA” will embed the LabTestPSA.ascx form in the eform.
(D) These are the nodes that hold the data as the eform is submitted. The node structure must match the database tables exactly. It is not necessary to include all the columns of a table, but the parent node must match the table name and any child node used must match a column name. As in this example with Medication, if multiple records for a table are being stored, a RecordId=”” attribute must be used which matches an attribute in the respective .ascx control. In this case, if you open the Medications.ascx file found in the Modules/All/Eforms folder you will find a series of eform input controls with RecordId=”” properties.
(E) As mentioned in (D), although not all table columns need to be listed, if a child node is present it must match the name of the table column exactly. Allowable attributes for child nodes are: • Required=”True” : A Required attribute will prevent a user from going past the data entry step without providing a value. • NotNull=”True” : A NotNull attribute requires that a value is present only when other fields of this record have a value. Typically used with a field that is non nullable in your database.
In the example provided, the Medication has a NotNull attribute which will prevent users from going past the data entry step without providing a Medication value only when other values for this record are present.
The system was structured so that all eform data is stored in a temporary state prior to eform approval. This temporary state is an XML string which in is stored in the EFormXml field of the Eforms table. When the eform is approved, this XML string is parsed and the data is inserted into the respective Caisis tables.
You may also find times where you would like to collect information, but there is no table/field in Caisis for this data. For this scenario, we provided a <NoTable> node. Under the NoTable node you can create child nodes that have no matching Caisis database fields. On approval, this data will be inserted in the field of the table specified in the PutDataInTable="" PutDataInField="" attributes. At MSK, we typically put this data in the “Encounters” table, “Notes” field.
You may create your eform from existing components(.ascx files), or you may create your own components. Part II of this document will discuss creating your own eform components.
In version 4.0, to register your new eform add a reference to it in the App_Config/EformRegistry.xml file.
Creating the .xsl stylesheet for the paper form view of entered data: After the data entry step, in the second “Review Data” step, the data just entered is presented in a format similar to a paper form. Fields can be edited via a pop up window on click. This “paper like” view of the data is generated by creating an .xslt stylesheet to transform your xml data. This step is optional. By default the system will generate a bullet point list of the fields you entered that does not resemble paper. If you would like to use a stylesheet, we recommend reusing code from existing .xslt files to minimize the amount of development time.
Please note, in future releases we will provide the option to hide the “Review Data” step. The eform could then more easily be used as just a consolidated interface to simplify common data entry.
