Audit

OpenVPMS has a simple but incomplete audit facility that needs to be explicitly enabled - see below.

Some records (eg invoices) record the 'author' - ie the name of the user who created them. However, this is not universal - for example no author is recorded on the customer record.

Audit Service
The audit service is very limited. It has never been developed beyond prototype phase. As such, it doesn't audit all of the operations performed on the database nor does it log the user that performed the operation.  It works by intercepting calls to the archetype service but it does not intercept the method where multiple objects are saved at once.

This method is used in many places, including:

* editing
* lookup merging
* customer merging
* invoice/credit reversals
* document generation
* customer balance updates
* till clearing

If you want to try it out, you need to edit applicationContext.xml located in <TOMCAT_HOME>/webapps/openvpms/WEB-INF/ and uncomment auditDao, auditService, autoProxyCreator, and auditServiceAdvisor so that things look as follows:
 

     <bean id="auditDao"
          class="org.openvpms.component.business.dao.hibernate.im.audit.AuditDAOHibernate">
        <property name="sessionFactory" ref="sessionFactory"/>
    </bean>

    <bean id="auditService"
          class="org.openvpms.component.business.service.audit.AuditService">
        <constructor-arg ref="auditDao"/>
    </bean>

    <bean id="autoProxyCreator"
          class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
        <property name="beanNames">
            <list>
                <value>archetypeService</value>
            </list>
        </property>
        <property name="interceptorNames">
            <list>
                <value>auditServiceAdvisor</value>
            </list>
        </property>
    </bean>

    <bean id="auditServiceAdvisor"
          class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
        <property name="advice" ref="auditService"/>
        <property name="patterns">
            <list>
                <value>.*ArchetypeService\.save</value>
                <value>.*ArchetypeService\.remove</value>
            </list>
        </property>
    </bean> 

Caching

There are multiple caches within OpenVPMS. These are used to improve performance, but in some cases and circumstances changes you make may not be immediately effective.

In general, if you update the database outside OpenVPMS, the changes:

• won't be seen immediately; or
• won't be seen until the object is edited, assuming it is not in the second level cache
• won't be seen till restart

The major caches are listed below:

1. Hibernate's second level cache, configured by ehcache.xml

Elements in this cache are set with the flag eternal="true", which means that they don't expire unless the cache capacity is reached, in which case the least recently used will be tossed out.

2. Archetypes

Elements in this cache can only be updated by:

• editing/loading archetypes via Administration - Archetypes
• Tomcat restart

3. Lookups

Elements in this cache can be updated:

• by editing via Administration - Lookups
• when cache capacity is exceeded - least recently used elements are discarded
• on low memory - elements will be shed from the cache to reclaim memory
• by Tomcat restart

4. Appointments/tasks

Elements in this cache can be updated:

• by editing via Workflow - Scheduling, Workflow - Tasks
• when cache capacity is exceeded - least recently used elements are discarded
• on low memory - elements will be shed from the cache to reclaim memory
• by Tomcat restart

5. Current user context

This includes the current:

• practice
• practice location
• stock location
• schedule view
• schedule
• work list view
• work list
• customer
• patient
• clinician
• user
• till
• deposit account

Refreshed by:

• switching objects (e.g changing practice locations).
• logging out/in

Help Topics

When you click Help in the top menu line or press Alt-H, a help topics window is displayed.

In the standard system this provides four links, Help Topics (which links to this), An Introduction to OpenVPMS (which links to the Introduction section), OpenVPMS Concepts and Glossary (which links to the Concepts section) and User's Forum (which links to http://www.openvpms.org/category/forums/users/general).

You can modify these and add more topics by editing the file help.properties in <TOMCAT_HOME>\webapps\openvpms\WEB-INF\classes\localisation.

If you are going to provide Local Procedures, then this is how to provide links to them.

Note that you can provide a simple local procedures document by writing what you need with your favourite word processor and then creating a pdf (called say localProcs.pdf). You can place this in TOMCAT_HOME>\webapps\ROOT and the help.properties entry will be like:

help.topic.5.title = Local procedures
help.topic.5.url = http://localhost:8080/localProcs.pdf

JXPath Extension Functions

OpenVPMS uses JXPath to perform expression evaluation within archetypes, macros, and reports.

The following extension functions can be used within expressions. They are grouped as General, Date, Expression, List, Party, Math, Macro, History and Reminder functions.

In the examples below you will see arguments like $patient, $customer, $visit, etc. This is a convenient shorthand for openvpms:get(.,'xxxx.entity') where xxxx is patient, customer, etc.  You can also use Application Fields and here also there needs to be a $ prefix, eg $OpenVPMS.location to access the current Practice Location.

Note that the $ shorthand is only available in the GUI environment. Specifically, it can be used in macros invoked the by user, but not in macros invoked by macro:eval() when generating forms and letters.

General Functions

Date Functions

Expression Functions

List Functions

The following functions operate on lists of objects.

Party Functions

The following functions operate on party archetypes, such as customers, patients, suppliers, and organisations.

Math Functions

Macro Functions

The following function can be used in document template content files. Its primary use is to provide standardised text strings for multiple documents.

History Functions

The patient history functions are restricted for use within Jasper Reports. They are designed to be used in sub-report expressions. E.g.:

 
$P{dataSource}.getExpressionDataSource("history:medication(openvpms:get(.,'patient.entity'))")

Reminder Functions

Reminders functions returning lists of act.patientReminder acts are restricted for use within Jasper Reports. They are designed to be used in sub-report expressions. E.g.:

 
$P{dataSource}.getExpressionDataSource("reminder:getReminders(., 1, 'YEARS')")

Links to other reference material

You may find the following useful.

Document merging with Open Office Writer

Reminder Export format

Reminders may be configured to be exported during reminder processing instead of mailed.

This file can be either comma or tab-delimited, depending on the Practice configuration.

The file contains the following fields:

Report fields

OpenVPMS supports reporting using:

• JasperReports - these are created using Jaspersoft iReports tool
• Microsoft Word documents with MERGEFIELDs
• OpenOfffice documents with User Fields

In order to create a report using any of these, you will need to know the names of the available fields.

The first step is to determine the template Type, from this you can get from the table below the name of the archetype. Note that three (those in CAPS) are not archetypes - see Special Reports below.

To determine the available fields to use in the report, looking at the corresponding archetypes (see Administration|Archetypes).

For example, the act.customerAppointment has the following nodes:

        <node name="id" path="/id" type="java.lang.Long" hidden="true" readOnly="true" />
        <node name="name" type="java.lang.String" path="/name" hidden="true" minCardinality="1" derived="true"
            derivedValue="'Appointment'" />
        <node name="customer" path="/participations" type="java.util.HashSet" minCardinality="1" maxCardinality="1"
            filter="participation.customer" />
        <node name="patient" path="/participations" type="java.util.HashSet" minCardinality="0" maxCardinality="1"
            filter="participation.patient" />
        <node name="appointmentType" path="/participations" type="java.util.HashSet" minCardinality="1" maxCardinality="1"
            filter="participation.appointmentType" />
        <node name="startTime" path="/activityStartTime" type="java.util.Date" minCardinality="1" />
        <node name="endTime" path="/activityEndTime" type="java.util.Date" minCardinality="1" />

Each of these nodes may be used in reports as follows:

Where a node refers to an archetype (e.g. the customer node is a collection of participation.customer), you can use "." to drill down on the nodes of that archetype.

In the above, "customer.entity.name" means:

1. retrieve the object associated with "customer.entity"; and
2. return its name node

Application Fields

The following fields are available to all reports¹, and represent the current selections in the application, if any.  Note that if on the Workflow|Scheduling or |Work Lists screen you select an appointment or task, these become the current aqppointment or task.  However, the fact that the associated customer and patient details are displayed in the left panel does NOT mean that these become the current customer and patient.  The current customer and patient are those displayed on the Customers|Information and Patients|Information screens.

These fields may also be used in XPath expressions, by prefixing the field name with a $ (i.e. they are available in expressions as variables).

¹ With the exception of JasperReports SQL sub-reports

Field Samples

Expression Samples

Note that the expr:var() function needs the name of the variable to test (eg 'OpenVPMS.appointment.startTime') whereas the date:format functions needs the actual variable, eg $OpenVPMS.appointment.startTime or

expr:var( 'OpenVPMS.appointment.startTime').

Application Fields as Report Parameters

JasperReports queries support parameters using $P{parameter name} syntax.

To use Application Fields as parameters, reference the field within a parameter's Default Value Expression.

E.g. to pass the current customer identifier, create a parameter with the following settings:

• Name: customerId
• Class: java.lang.String
• Is For Prompting: Yes
• Default Value Expression: "$OpenVPMS.customer.id"

Note that Class must be java.lang.String to avoid compilation errors, and that the parameter must be prompted for otherwise the $OpenVPMS.... will not be replaced with its current value.

If there is no current item (ie customer in the above case) then the parameter will be initialised to null.  Hence if the parameter was set as follows:

then the SQL code should be like the following - note the comparison to the string "0" to handle the 'all' case:

and for the display of the parameter in the report, you might want to use an expression like the following so that the 'no current' case is clearly identified:

($P{customerID}==null)||($P{customerID}.compareTo("")==0)?"--NONE--":$P{customerID}

Special Reports

These are special reports that are generated by running queries that:

• derive values
• return partial objects
• return multiple objects

For CUSTOMER_BALANCE, the fields are:

For GROUPED_REMINDERS, the fields are:

For WORK_IN_PROGRESS_CHARGES, the report is supplied with Invoices, Credits and Counter charges (act.customerAccountChargesInvoice, act.customerAccountChargesCredit, and act.customerAccountChargesCounter archetypes respectively), that have an In Progress, Complete or On Hold status.

The available fields are therefore the nodes present in each of these archetypes.

Reports and Documents

If you do need to create of modify documents and reports, the following should be useful.

OpenVPMS uses two 'vehicles' to generate printed (or pdf) output: OpenOffice (specifically its 'soffice' component) and JasperReports. Note that since OpenOffice can handle Microsoft Word documents, you can happily use Word rather than Open Office Writer to prepare letters and forms.

Which of these two is used depends on the document content set for the document template. (See Administration|Templates and Create/Edit Template.) If the document content is a .jrxml file, then JasperReports is used, if it is an .odt or .doc or .docx file then OpenOffice is used.

To create and edit the .jrxml files you use JasperSoft's iReports, specifically version 5.0.4. (The use of later versions is possible but the compatibility mode option needs to be enabled.)

Note that JasperReports is used for any document that has more complex datasets such as invoices, statements, reports etc as these typically have multiple rows of data and require groupings and other data processing functions not available in OpenOffice. These are also rarely changed except during implementation.

OpenOffice is used for customer, supplier and patient documents. These are more likely to be modified and added to by the practice so a standard word processor editor is more appropriate.

The reports and forms/letters/documents get data in two ways:

• Reports (ie things run from the Reporting|Reports menu) are all handled by JasperReports. These MUST have their Report Type set to 'Report' in their document template. The report parameters (if any) are passed as 'Parameters' and the 'datasource' is set to access the MySQL database.  The report then uses SQL to extract the required information from the MySQL database. Selection criteria and other parameters are entered via a report criteria screen.
   
• Forms, letters, and system documents (ie invoices etc) may be handled by either JasperReports (for the complicated ones) or OpenOffice. For these the Report Type in their document templates will always be other than 'Report', eg 'Customer Invoice', 'Patient Letter', etc. In both cases an appropriate dataset is made available - and this is determined by the Report Type. For OpenOffice (or M/S Word) this is accessed via merge fields, ie the facility that is commonly used in word processors to do mail merge. For JasperReports, the 'datasource' is set to access this dataset. In both cases the field names are the same. Note that the term 'field name' is a little misleading - as well as things that look like names such as customer.entity.name and patient.entity.species, you can use more complicated expressions like [openvpms:get(party:getPatientOwner(.),'lastName')] and [macro:eval('standardConditions')]. Expressions are always enclosed by square brackets.

  The available field names are documented here; the available expressions here.

  Input parameters (commonly user input to letters) are entered via a parameter input screen.

Open Office Notes
The simplest way to generate a new .odt template is to use the sample templates included in the distribution.  These call out almost all the available fields and you can copy the required fields from the sample document.

Microsoft Word Notes
The simplest way to generate a new .doc (or .docx) template is to use the sample templates included in the distribution.  These call out almost all the available fields and you can copy the required fields from the sample document.

Note that although Word supports conditional fields, these are not implemented by the Open Office component used by OpenVPMS. Hence if you need conditional fields (eg to switch between 'him' and 'her' based on the patient's sex) then you will either need to use .odt templates. Alternatively you use the macro:eval function to run a macro that will return his or her depending on the sex.

iReports Notes
The following is not intended to be 'how to use iReports' but rather a set of notes that may help you when you are examining an existing report and trying to understand how it works.

Field names: For reports, when the datasource is the MySQL database, the field names are the names of the fields returned by the SQL query. Otherwise the datasource is a data collection and the field names are used the access the data collection - either via simple archetype dot notation (eg customer.entity.name), or via xpath expressions enclosed in square brackets (eg [party:getPartyFullName(.)] ).  While the former feels quite normal - ie using $F{customer.entity.name} is a reasonable syntax, the latter appears peculiar - $F{[party:getPartyFullName(.)]} does not look like a normal way to access something.  However, it works - what is happening is that the OpenVPMS code examines the name of the field, sees that it starts with '[' and ends with ']' and knows to interpret the contents as an xpath expression.

Sorting and Grouping: The Grouping facility assumes that the records are appropriately sorted. That is, if you use grouping to organise the output by patient/date/product type then the data must be sorted in this order - defining the groups does not do the sorting for you. For SQL based reports, you do the sorting in the SQL query. Otherwise you can do it either in the datasource specification (see below) or using the inbuilt facility - this is accessed via the Report Query icon on the Designer view, and then pressing the 'Sort Options...' button.

Note that using the inbuilt sort, you can sort using fields (including ones that are xpath expressions) and variables, whereas in the datasource specification (see below) you can only sort by node names.

Sub-reports: [Note that although JasperReports support sub-reports anywhere in the report, the OpenVPMS implementation only supports sub-reports in either the Detail or Summary bands.] When using sub-reports you must specify the datasource for the sub-report in the main report. If the main report is using the MySQL database as the datasource, then the datasource part of the sub-report field in the main report will be set like the following:

However, if the main report is not using MySQL as the datasource (ie this is the sub-report for Customer Invoices or Customer Statements) then the datasource part of the sub-report field in the main report will be set like the following:

The datasource expression can also have a second argument as follows:

 $P{dataSource}.getDataSource("items", new String[]{"target.patient.entity.name", "target.startTime"}) 

Here, the first argument "items" specifies the node in the report's data source (eg act.customerAccountChargesInvoice for an invoice), and hence this accesses the invoice's items. The strings in the second argument specify the names of the nodes to sort the data by. Note that these must be node names, they cannot be xpath expressions.

Now the 'items' node of the act.customerAccountChargesInvoice archetype is a collection of actRelationship.customerAccountInvoiceItem archetypes, and in these the node named 'target' is the collection of act.customerAccountInvoiceItem archetypes which are the invoice line items.

Hence in the sub-report, the field names are target.xxx where xxx is the node within the act.customerAccountInvoiceItem archetype.

NOTE that the Subreport Expression contains the name of the Content of subreport - not the template name.  Hence if you upate say the Invoice Items template with a modified content file (say InvoiceItems-BE-1.jxrml) then the Invoice template will not be able to find the items content because you have changed its name. That is, if you are editing the content of a subreport, you must not change the name of the content file.

Furthermore you should not have multiple templates that have content of the same name - IF one of the templates is a subreport. This is because when the subreport content is used when the report is run, it is highly likely that the wrong one will used since there are multiple content files with the same name.

iReports Preview: If you building a report that uses the MySQL datasource, then you can use iReports Preview facility. To set this up you need to add the datasource. Click the Report Datasources button:

Now press New to create a new 'Database JDBC connection' and then set the details as follows:

Note that if you are developing a report that uses subreports, then for previewing to work, the 'Subreport Expression' parameter needs to be like:
  $P{SUBREPORT_DIR} + "RPT Practice Summary_CountInvoicedCustomers.jasper"
whereas, for production use in OpenVPMS, it needs to be like:
  "RPT Practice Summary_CountInvoicedCustomers.jrxml"

Email Letterhead Support
If reports and documents are set up to be printed on letterhead paper, then if they are emailed rather than printed, one needs a facility to insert the letterhead when the item is being emailed but not if it is being printed.

This is achieved through the IsEmail property which is supported for OpenOffice and JasperReports templates.

To use it in OpenOffice templates:

1. Create a new field by going Insert -> Fields -> Other -> User Field
2. In Name, enter "IsEmail" (without quotes)
3. In Value, enter "unset" (without quotes)
4. Click on the green tick
5. Create a section to display when printing by going Insert ->Section
6. Name it "Print Letterhead"
7. Tick the Hide box
8. Enter: IsEmail == "true" in the With Condition box
9. Click OK
10. Repeat 5-9 for a section named "Email Letterhead" but enter IsEmail == "false" in the With Condition Box.

The "cartrophen first reminder.odt" and "desex first reminder.odt" templates in the release distribution demonstrate this. 

To use it in JasperReports templates:

1. Add a Boolean parameter, IsEmail
2. For elements that should only be displayed when emailing, set their "Print When Expression" expression to: $P{IsEmail}.equals(Boolean.TRUE)
3. For elements that should only be displayed when printing/previwing, set their "Print When Expression" expression to: $P{IsEmail}.equals(Boolean.FALSE)

Any of the JasperReports in the release distribution illustrate this.

Setup

This section contains topic relevant to setting up the system.

Note that if you do edit Administration|Organisation items (say to change an email address), then the new values will not become available until the next time you log on (because these organisation settings are fetched once at logon time to improve performance).

 <bean id="mailSender" class="org.openvpms.web.component.service.MailService" scope="prototype"/> 

<bean id="mailSender" class="org.openvpms.web.component.service.MailService" scope="prototype">
    <property name="javaMailProperties">
       <props>
           <prop key="mail.smtps.debug">true</prop>
       </props>
    </property>
</bean>   

#
# Script to create the openvpmsX database, and add a single user 'openvpms',
# with all privileges
#

CREATE DATABASE `openvpmsX` /*!40100 DEFAULT CHARACTER SET utf8 */;

GRANT ALL PRIVILEGES ON openvpmsX.* TO 'openvpmsU'@'localhost'
    IDENTIFIED BY 'openvpmsP' WITH GRANT OPTION;

GRANT ALL PRIVILEGES ON openvpmsX.* TO 'openvpmsU'@'%'
    IDENTIFIED BY 'openvpmsP' WITH GRANT OPTION;

COMMIT;

    <!-- Needed by spring if you want to deploy app more than once as different name. Change value
      -  to something unique -->
    <context-param>
        <param-name>webAppRootKey</param-name>
        <param-value>openvpmsX</param-value>
    </context-param>

  <!-- For jurisdictions that use rabies tags, uncomment the following -->
  <!--
  <propertyMap name="archetype">
      <property name="shortName" value="entityIdentity.rabiesTag"/>
  </propertyMap>
  -->

  <!-- For we use rabies tags -->
  <propertyMap name="archetype">
      <property name="shortName" value="entityIdentity.rabiesTag"/>
  </propertyMap>

    <propertyMap name="archetype">
         <property name="shortName"
                   value="entityIdentity.petTag"/>
    </propertyMap>

    <!-- suppress pet tags   
    <propertyMap name="archetype">
         <property name="shortName"
                   value="entityIdentity.petTag"/>
    </propertyMap>
    -->

Style - Colours

For most things you can change the display colour via the appropriate Administration screen - for example Users to set the clinician colour on the scheduling and work list screens.  However, for three things you have to change files in the styles directory.

The files default.stylesheet and default.properties, are located in the <TOMCAT_HOME>/webapps/openvpms/WEB-INF/classes/style folder. It is sensible to make a backup copy of these files before editing them. Having saved the file(s) you will need to restart Tomcat to get the changes to have effect.

Note that it may be better to use the site over-ride facility - see Style - Site.

The colours are set as Hex codes - see the colour block at the bottom of this page.

Appointment/Task Status
You can change the colours used to highlight the status of appointments on the scheduling screen and tasks on the work list screen.

In the default.stylesheet file look for lines containing ScheduleTable.xxx where xxx is PENDING, CHECKED_IN, IN_PROGRESS, etc. You will find in the following block a line like <property name="background" value="#ffffff"/>.  Change the value as required.

Screen Colours
If you want to change the standard OpenVPMS green background on the screens to another colour, in the file default.properties, look for the line containing theme.colour  = '#339933'. Change the 339933 to the get the required colour.  In the same part of the file, you will also find the title, button and selection colours as well as the colours used for the various medical history items.

Reminder Status
You can change the standard green/orange/red settings for the reminder not due/due/overdue status.

In the file default.properties, look for the line containing reminder.notdue.colour.  This and the due and overdue lines set the colours. Change as required - but note that this will not change the colour of the red bell icon used to warn of an overdue reminder.

History Colours
If you want to change the colours of items on the Medical Records screen, in the file default.properties, look for the line containing "# Patient history colours" - the following lines set the colours for the different items.

Sample Colours
The sample block below shows the hex codes of the set of 'web-safe' colours. You will find 'OpenVPMS Green' in the second column, 10 down.  See also this forum post for a tool to compare colours.

Style - Column Widths

You can adjust the size of some column widths to suit local usage by overriding properties in the default.properties file. This is done by adding the property to a file named site.properties in the <TOMCAT_HOME>/webapps/openvpms/WEB-INF/classes/style folder. Having saved the file you will need to restart Tomcat to get the changes to have effect.

Medical Records: Clinician Width
You can change the size of the Clinician field (shown if you set the 'Show Clinician in History Items' option for the Practice). You may want to either increase this to show long names, or decrease it if you use just initials.

The width is controlled by the history.clinician.width setting.

Selector Field Width
You can change the size of the 'selector' fields - ie those with the binocular icon following them. You may want to do this if you find that the standard size is often too narrow to show all the data.

The width is controlled by the selector.width setting.

Style - Labels

The default for label alignment is left so that things look as follows:

However, you can change this to right so that the above becomes:

To change the label alignment you need to edit default.properties, located in <TOMCAT_HOME>/webapps/openvpms/WEB-INF/classes/style/default.properties- and having edited it (after first taking a backup copy) you need to restart Tomcat to get the changes to have effect.

Go to the section on Label alignment. i.e.:

 #
# Label alignment.
# This specifies the horizontal label alignment when:
# . editing and viewing objects
# . inputting report parameters
# Possible values are 'left' and 'right'
label.align = 'left'
  

and change 'left' to 'right'.

Note that it may be better to use the site over-ride facility - see Style - Site.

Style - Site

Instead of customising default.stylesheet and default.properties located in the <TOMCAT_HOME>/webapps/openvpms/WEB-INF/classes/style directory, you can place these changes into files named site.stylesheet and site.properties in the same directory, and they will override the default values. For site.stylesheet, enclose all styles in a root <stylesheet> element. For example:

 <stylesheet>
    <style name="SomeLayout" type="nextapp.echo2.app.SplitPane">
        <properties>
            <property name="resizable" value="false"/>
            <property name="separatorPosition" value="${SomeLayout.separatorPosition}"/>
            <property name="separatorHeight" value="0px"/>
        </properties>
    </style>
    <style name="SomeOtherLayout" type="nextapp.echo2.app.SplitPane">
        <properties>
    </style>
</stylesheet> 

However, it is important to understand how the facility works.  There are two problems:

1. styles cannot refer to styles defined in different stylesheets

So you can't have a base-name attribute in site.stylesheet that refers to a style defined in default.stylsheet. You need to either:

• incorporate the original style in the custom style
• copy the original style to site.stylesheet

2. styles that have the same name must all be copied

If a style name appears for different classes (e.g. "default" for nextapp.echo2.app.Label, and nextapp.echo2.app.WindowPane), and you want to customise the Label version, you have to copy all other occurences of "default" as well. This is due to a bug/feature in the echo2 framework, that replaces all instances of a style when merging stylesheets.

Raised as https://openvpms.atlassian.net/browse/OVPMS-1387

Tuning

This section covers areas that affect the performance of the system. It is anticipated that more topics will be added here in the future.

Medical Records Retrieval
The standard system can perform slowly when retrieving medical records for a patient with a long history. The apparent performance can be improved by limiting the number of visits retrieved for each query of the medical history. The standard system retrieves the complete medical history and then pages it out 20 visits at a time.

One can change this behaviour by limiting the number of visits on each query. If this is set to a number less than 20, then each 'page' of the medical history will display just that number of visits, and as you page through the history, a new query will be issued to get the next block of visits.

To limit the number of visits retrieved on each query to say 5, create a file called QueryFactory.properties containing one record as follows:

 act.patientClinicalEvent org.openvpms.web.workspace.patient.history.PatientHistoryQuery,maxResults=5  

This file needs to be placed in the folder <TOMCAT_HOME>/webapps/openvpms/WEB_INF/classes

Hardware Selection
As always, the general advice is to buy the fastest you can afford. Adding more memory will improve performance provided that MySQL is configured with large buffers. In fact, given a 64-bit operating system, there is no reason that the database cannot be held fully in memory.

MySQL
MySQL configuration is a black art.  Parameters important for performance are:

innodb_buffer_pool_size - set as large as possible

query_cache_size - say 50MB

query_cache_type - ON

query_cache_limit - say 2MB

XPath Functions

OpenVPMS supports the XPath 1.0 functions and operators to perform expression evaluation within archetypes, macros, and reports.

By far the most commonly function is concat, used to concatenate strings.  Hence concat('ab','34','ef') yields 'ab34ef'.

However, others are used. One terrifyingly complex example is that used to generate the customer's name.  It is as follows:

concat(/details/companyName,substring(concat(/details/lastName,',',/details/firstName),0,number(not(/details/companyName))*string-length(concat(/details/lastName,',',/details/firstName))+1)) 

This returns the companyName if there is one, else lastName,firstName. It relies on the concatenation of two mutually exclusive strings, the first one being empty if the condition is false, the second one being empty if the condition is true. This is called "Becker's method", attributed to Oliver Becker.

In the above you can see the functions concat, substring, number, not, string-length, and the operators * and + being used.

The table below shows the available functions. (Others are defined but are not relevant to our use.)

Below are the operators used in XPath expressions. In the table below, e stands for any XPath expression.

HL7

OpenVPMS supports a subset of the HL7 2.5 messaging standard, to enable transfer of clinical and administrative data to other applications.

Patient Administration Messages

The following Patient Administration messages are supported:

Pharmacy Messages

The following pharmacy messages are supported: