javascript hit counter

Frequently Asked Questions

How much memory should I allocate to Apache™ Tomcat Servlet Container (Tomcat)?
The amount of memory you should allocate depends on several factors: the number of applications running on the server, the amount of memory in use by the applications running on the server, the maximum number of people who will be connecting to and using Promiso at any one time, the number of Promiso reports to be run at any one time, and how much RAM is currently on your server. If your server has 512MB - 1GB of RAM, a suggestion may be to allocate 256MB of RAM. If you do not allocate enough memory, the users will encounter Out Of Memory errors and Tomcat will crash.
Where can I find support or information about Tomcat?
Information about Tomcat can be found at: http://tomcat.apache.org
How is Promiso licensed?
Licensing is based on the number of staff and students for whom workload is maintained, not the number of concurrent connections or users. For example, a site with a 1,600-pack license can define and activate as many as 1,600 Staff codes.
When I enter the URL to start Promiso, all that appears is a 404 page.
Check that the context created in Tomcat was entered correctly, making sure that no extra spaces exist in the Document Base path. Also, check that the URL entered in the browser matches the Tomcat context exactly: the path name is case-sensitive.
When I start Promiso, a message appears about not being able to establish a database connection.
You should report the problem to an in-house System Administrator. Possible causes for the inability to establish a database connection are:
• temporary loss of network connection
• the database server, Microsoft® SQL Server™ or MySQL™, is stopped or paused
• incorrect database name specified in INFOMED.properties file
• incorrect IP address specified in INFOMED.properties file
• the server housing both Tomcat and the database server was rebooted and the applications are set to start automatically but Tomcat started before the database server was up and running: to remedy this situation, restart Tomcat
Users are experiencing an extreme slowdown in logging on to Promiso, or cannot log on at all.
It is possible that the maximum number of threads set in Tomcat has been reached: this value can be increased by your in-house System Administrator. It is also possible that Tomcat has run out of allocated memory: this, too, can be increased by your System Administrator.
Why does Promiso just disappear when I log on?
It is likely that popup- or ad-blocking software installed on the workstation is preventing Promiso from running.
When I start Promiso, the Logon page does not appear. Why?
Tomcat or the server itself may be down temporarily: please contact your in-house System Administrator to see if this is the case. Another possibility is that Tomcat has run out of resources, such as memory or threads: both of these settings can be increased by your System Administrator to accommodate heavier loads.
Instead of a table, a “java.lang.NullPointerException” appears.
When an update was installed, the update script either did not run or did not run properly: please contact our Support Desk for assistance.
When logging on to Promiso, why does a red X appear in place of the main menu?
This usually indicates that Promiso cannot find the correct version of the Java Plug-in, or there was a problem with the Java Plug-in installation. If the correct version is installed, open the Control Panel for the Java Plug-in to check that it installed properly. If necessary, uninstall the plug-in and re-install it.
Why am I able to view only three professions at most on the Staff Code Maintenance page or the Code Maintenance for Professions page?
The maximum number of viewable professions is controlled by a property in the INFOMED.properties file. The default setting is to display only three active professionsat a time. If you would like to be able to see more, please contact your in-house System Administrator to change the setting.
Where can I find information about individual reports?
There is a comprehensive online document outlining each report, describing how the information is gathered for presentation on the report, and providing explanations for puzzling results: in the main menu, expand Help and then select Reports Reference Guide.
How long should I expect to wait for a report to be generated?
There are many factors that determine the speed at which a report is generated:
• current overall network traffic
• current load on the server housing Promiso
• available memory on the server housing Promiso
• the extent of the conditions applied to the report
• the information to be reported (workload reports take less time to generate than attendance day or status reports for the same span, for example)
Therefore, it is not possible to predict how long it should take to generate a report. If you have notice that a report takes longer to run than usual, please contact our Support Desk.
I have discovered a demographic record with an incorrect ID. Can I edit the ID?
An ID can be edited on the Demographic Form by a user who has been granted Read/Write permission to the form for at least one profession. To edit an ID, retrieve the demographic record of interest, enter the correct ID, and save the record. An ID cannot be edited to be the same as one that already exists.
I am trying to edit an ID on the Demographic Form but am getting a message that the ID already exists. Is it not possible for the record with the incorrect ID to be merged with an existing record?
The short answer is no. However, if you have discovered that there are two IDs representing the same service recipient (one correct, one incorrect), you can take the following steps to remedy the situation:
• on Form A, select the profession for which workload and/or counting field data has been entered for the service recipient of interest and enter the incorrect ID
• using the Record Header Search (F2) feature, find all the data that has been entered against the incorrect ID for each record header and write it down
• return to Form A and enter the correct ID for the service recipient; re-create the records that were entered for the incorrect ID as per the notes you made in the previous step
• verify that the records you have re-created are identical to those for the incorrect ID
• on Form A, enter the incorrect ID and use the Record Header Search (F2) feature to delete each record header
• repeat these steps for each profession for which workload and/or counting field data has been entered
• once all the record headers for the incorrect ID have been deleted, open the Demographic Form, retrieve the record with the incorrect ID and delete the record
Why does a service recipient not appear in the ID list on Form A for a unit where services were provided?
A service recipient may be missing from an ID list for a given unit because:

The Purging feature in ADT Interface Server is enabled and the settings are such that the demographic record is deleted from Promiso before the user has a chance to enter data. For example, suppose an A01 (admit/visit notification) message was sent by the ADT system for the service recipient on the first of the month, the Purging feature is set to purge demographic records after 14 days if no Form A data has been entered, and no Form A record was entered for the service recipient for the first two weeks of the month; come the 15th, the demographic record for the service recipient would be deleted. The service recipient would have appeared in the ID list on Form A for the unit for the first two weeks of the month only. It might be a good idea to revise the settings for the Purging feature to avoid this problem.

An A03 (discharge/end visit) message was sent after the A01 message. This removes the reference to the unit from the demographic record in Promiso, so the service recipient will no longer appear on the ID list on Form A for that unit. The user will have to do a lookup (by clicking the Search button or pressing the Ctrl + L shortcut key combination) to load the service recipient into the ID list on Form A for the unit where the services were provided before recording the data. An A03 message does not cause a demographic record to be removed from the Promiso database.

An A11 (cancel admit/visit) message was sent after the A01 message. This removes the reference to the unit from the demographic record in Promiso, so the service recipient will no longer appear on the ID list on Form A for that unit. The user will have to do a lookup (by clicking the Search button or pressing the Ctrl + L shortcut key combination) to load the service recipient into the ID list on Form A for the unit where the services were provided before recording the data. An A11 message does not cause a demographic record to be removed from the Promiso database.

An A08 (update patient information) message, or any message processed by ADT Interface Server other than those listed above, was sent with a unit that differs from that in the original A01 message. This updates the reference to the unit in the demographic record, so the service recipient will appear in the ID list on Form A for the most recent unit instead. The user will have to do a lookup (by clicking the Search button or pressing the Ctrl + L shortcut key combination) to load the service recipient into the ID list on Form A for the unit where the services were provided before recording the data.

A Promiso Administrator has purged the ID list for the unit using the ID List Maintenance utility. This removes selected service recipients from the ID list but does not remove demographic records from the Promiso database. The user will have to do a lookup (by clicking the Search button or pressing the Ctrl + L shortcut key combination) to load the service recipient into the ID list on Form A for the unit where the services were provided before recording the data.

© 2017 InfoMed Development Corporation. All rights reserved.