Contents 

InfoPath Resources

• InfoPathDev.com
• InfoPath SDK

Form Entry Use Cases

Complete Form Entry Use Case

• Complete Login use case.
• Select Form Entry use case.
• Enter patient name in search box.
  • System will retrieve all patients matching the entered search term.
• Select appropriate form.
  • A request for /openmrs/formDownloadServlet is sent to server. FormDownloadServlet handles request and generates an XML response that contains the form schema (xsd) along with information that will tell the browser to open InfoPath to display the form. Unless previously instructed, the browser will prompt you to Open or Save the document. The XML below helps the browser figure out what it needs to do with the response.

<?xml version="1.0"?>
<?mso-infoPathSolution name="Demo Form" href="http://localhost:8080/openmrs/formentry/forms/DemoForm.xsn" solutionVersion="" productVersion="11.0.6357" PIVersion="1.0.0.0" ?>
<?mso-application progid="InfoPath.Document"?>

• Select the "Open with InfoPath" option.
  • InfoPath will look for the XSN form at http://localhost:8080/openmrs/formentry/forms/DemoForm.xsn and attempt to open it. If successful, the form will be displayed. Otherwise, InfoPath will display an error message. See InfoPath_Notes#Troubleshooting for more information on specific errors.
• Enter data into the form. This may require stepping through several pages of a form.
• Select Submit button on last page of form.
• InfoPath POSTs a request containing your form data to the FormUploadServlet.
• FormUploadServlet creates a FormEntryQueue record, sets its XML data field with XML form data from the post, and stores the FormEntryQueue in the database.

Process Form Entry Queue Use Case

• Scheduler spawns a ProcessFormEntryQueueTask every X seconds.
• ProcessFormEntryQueueTask delegates to FormEntryQueueProcessor.
• FormEntryQueueProcessor iterates through the FormEntryQueue.
• FormEntryQueueProcessor transforms XML data in FormEntryQueue using an XSLT associated with the given form.
• FormEntryQueueProcessor creates and stores the HL7InQueue record.

Process HL7 Queue Use Case

• Scheduler spawns a ProcessHL7InQueueTask every X seconds.
• ProcessHL7InQueueTask calls HL7InQueueProcessor.
• HL7InQueueProcessor iterates through the HL7InQueue
• HL7InQueueProcessor processes all HL7InQueue records.
• HL7InQueueProcessor creates an Encounter and Observations based on the HL7 messages in the queue.

Troubleshooting

If InfoPath is not behaving as expected (changes aren't being reflected, etc), the problem can often be solved by clearing the cache. You can run the following on the Windows command line or create a batch file.

"C:\Program Files\Microsoft Office\OFFICE11\infopath.exe" /cache ClearAll

ClassCastException while trying to Download Schema

Problem

Solution

No solution yet. It first appeared that this was caused by a missing concept_numeric row (concept with datatype Numeric does not have a concept_numeric row). However, I've tested this theory and it now appears that I am not correct. Note the error before the exception ("Narrowing proxy to class org.openmrs.ConceptNumeric - this operation breaks"). This is just a warning, but might have something to do with the exception.

Partial solution. It seems that this problem is a side effect of a problem with fetching ConceptNumeric objects out of Hibernate's cache. If the concept has already been loaded into the cache as a Concept object, then the request for the matching ConceptNumeric returns a Concept object instead...leading to the CastCastException. This has been temporarily solved by (1) a hack in the ConceptService that refetches a ConceptNumeric object if necessary and by (2) re-arranging the schema generation so that the affected code is performed last (right before the request is completed). We are still working on (in need of) a cleaner fix.

Comments

ConceptNumeric extends Concept.

Permission Denied error when using taskpane

Problem

When opening the taskpane either in preview or edit mode, you receive:

This will usually occur when accessing the xml dom using:

Solution

Change your Internet Security settings:

1. Make sure http://localhost(or your site url) is a "Trusted Site".
   1. (In Infopath menu) Tools -> Options -> Internet Options
   2. Click on the Security tab
   3. Select "Trusted Sites"
   4. Click "Sites" button
   5. Add http://localhost (or your site url) if it is not there
   6. Click Ok
2. Make sure your "Trusted Sites" can do cross-site scripting
   1. (In Infopath menu) Tools -> Options -> Internet Options
   2. Click on the Security tab
   3. Select "Trusted Sites"
   4. Click "Custom Level"
   5. In Miscellaneous --> Access data sources across domains
   6. Check "Enable"
   7. Click Ok

Login required when searching from taskpane

Problem

When opening the taskpane for a search (such as for looking up the location or a new problem) you are required to login again. When completing the form and returning to the the main OpenMRS application you are also requested to login again.

Solution

Ensure that you are using the correct URL for OpenMRS. If you have set a specific URL for infopath forms in the global properties table (so that you can access forms over a LAN, for example) be sure to use the same URL when opening OpenMRS from the local machine.

In other words, if you have a fixed IP for the server in the formentry.infopath_server_url property, don't use

http://localhost:8080/openmrs

to browse/view/open the web application, use the fixed IP you placed in the global property.

This problem also appeared when migrating to Spring 2.5 due to a reversal in the order in which module's urlMappings and the core's urlMapping are loaded. Upgrading your modules and the openMRS core to the latest builds should fix the problem. Technically, the error can be fixed by adding the 'order' property to the urlMapping beans for both the core and all modules, where the modules have a lower value than the openMRS core.

Same scope elements with the same name

Problem

When opening an InfoPath document, it reports an error of this kind.

FormEntry.xsd#/schema/complexType[121][@name = 'sample_concept_question_here_type']/sequence[1]/element[9][@name = 'unknown']
In the same scope elements with the same name, 'unknown', have to be the same type.

Solution

select concept_id, answer_concept, answer_drug, count(*) as cnt from concept_answer group by concept_id, answer_concept, answer_drug having cnt > 1;

Back up your database and run the following SQL script.

# did you remember to backup the database?

# go into openmrs db
use openmrs;

# delete all tuples with the same concept_id and answer_concept by adding temp index
alter ignore table concept_answer add unique index tmp_uniq_idx (concept_id,answer_concept,answer_drug);

# remove the temp index
drop index tmp_uniq_idx on concept_answer;

When submitting an infopath form the message "form submitted successfully" appears but the data does not go into the database

Problem

When you submit an infopath form the message "form submitted successfully" appears. However when you go to the encounter list for the patient you just entered a form for, the encounter does not appear, even after waiting a few minutes. This can be caused by the "Process Form Entry Queue" task or the "Process HL7" task not being turned on in the scheduler.

Solution

Go to "Administration" and click "Manage Scheduler". For the two tasks "Process Form Entry Queue" and "Process HL7", check that "start on startup" is true and "running" is true. If "running" is false, tick the task and click "start". If "start on startup" is false, click the task name, click "schedule", tick "start on startup" and save.

Multiple validation errors in infopath in different locales

Problem

When you open an Infopath form to perform data entry, almost every non-free-text field in the form gives validation errors.

Solution

This can occur because the form's xsn has been rebuilt in a different locale than the locale originally used to design the form in Infopath. During the 'rebuild xsn' process, the form's xsd file is updated to reflect the current locale, but the original data bindings in the pageXX.xsl files are not updated. To solve this, change your locale to the same locale that was used when the form was designed originally, rebuild the form, and the switch back to your desired locale.

After doing an upgrade, on form sumbit, you get schema item does not match DTD definition error

Problem

After upgrading from openmrs 1.4 to openmrs 1.6, we ran into a problem where forms could not be sumitted, and we were getting an error that our schema definition didn't correspond to the DTD definition of a specific element.

Solution

This has something to do with a DTD change for how infopath marks insertion points for repeating tables. After upgrading from 1.4 to 1.6, we had to identify all the infopath forms in our system that contained repeating tables, and download the xsn, resave on the desktop with a new filename, and then re-upload.