1.

How to enable client-side validation for an input field on work object form
Client-side validation ensures that data entry on a form is correct before the form is submitted to the
application server. For example, if a user enters an incorrect date into a date field (for example
2/30/2007), an error notification appears when the focus exits the date field.
Client-side validation can occur on a property received from an external system or on a Process
Commander property for which you enter data on a form. Enabling client-side validation on a property on
a Harness rule requires you to:

 Create a custom Rule-Edit-Validate rule. This allows you to define a Java routine that tests the
validity of a data entry value.
 Select the Enable Client Side Validation check box on the Harness form on which the property
requiring validation resides.

 Add a JavaScript validator to the Harness form. The JavaScript validator resides in the Rule-File-
Text instance.

Suggested Approach
For information on creating a Rule-Edit-Validate rule and selecting the Enable Client Side Validation
check box, see the Application Developer Help system.
To add a JavaScript validator to the Harness form, use the following procedure:
1. Add your new custom Rule-Edit-Validate rule to the Input Processing section of the Property
form. The sample below shows a Rule-Edit-Validate rule of NotFutureDateTest:

2. Create a new JavaScript validator by performing a Save As on the Rule-Text-File instance named
pega_validators. The sample below shows a new Rule-File-Text instance of
pega_validators_Test:
 3. Add code similar to the following to the File Source section of the new Rule-File-Text instance:
IMPORTANT: The code below is used for demonstration purposes. Your code may differ
depending on the property you are validating.

/* IsNotFutureDateTest */
var ruleEditValidate_notFutureDateTest = new
validation_ValidationType("notfuturedatetest",
ruleEditValidate_isNotFutureDate);
ruleEditValidate_notFutureDateTest.addEventFunction("onchange",
ruleEditValidate_isNotFutureDate);

4. Add the new Rule-File-Text instance (in our example, pega_validators_Test) to the Scripts
section of the Harness form:

2. How to specify error message text within the Java code of an edit validate rule
I have a question concerning the best way to have "friendly" and meaningful error messages for property
validation.
We have a flow action that allows users to specify a timeline which is essentially a list of dates entered
into Date-Calendar formatted properties. The properties use the IsValidDate Rule-Edit-Validate rule.
This has the advantage that validation is done out-of-the box every time the Flow action is submitted. A
red X appears with the tooltip "Invalid date specified for IsValidDate". Feedback from the users is that
they would like a friendlier error message, one that refers them to the correct date format for example.
Rule-Message rules seem to be designed to allow configurable messages. What is the best way to
associate a Rule-Message with a Rule-Edit-Validate? There is the option to use a Rule-Obj-Validate but
that needs to be called from within an activity. This would require at least two more rules just to change
an error message. Help mentions using theProperty.addMessage() to pass a (optionally parameterized)
Rule-Message into the error message that is returned from the Java in the Rule-Edit-Validate. However, I
have found that this only adds the Rule-Message text to the existing text.
Where is the "Invalid Date specified for IsValidDate" text held or originating from? I could find no rule that
may provide it and reluctantly came to the conclusion that it may well be buried in the Java code
somewhere. I appreciate that for larger scale validation, especially one that needs to take localization
into account, a Rule-Obj-Validate is the best way to go. But in our case where the standard functionality
does everything perfectly, apart from the message text, that approach seems a bit too much for such a
modest change.
Suggested Approach
The Rule-Message used if a Rule-Edit-Validate fails is always the PropertyInfo-EditValidate rule. There
is currently no way to override this. An enhancement request to allow a message key to be specified on
the Rule-Edit-Validate itself will be considered for a future release.
Meanwhile, in writing a Rule-Edit-Validate, you do have access to the property being edited via a
ClipboardProperty Java variable named "theProperty". The other variables established are "theValue"
(the String value of the property) and "itsType" a char representing the type of the property (one of the
constants from PropertyInfo TYPE_*). Therefore it would be possible for you to ADD an additional
message to the property within the Rule-Edit-Validate itself (as you note in your question). This is the
currently available solution to tailor the message.

3. XML Parse Rules and Validation

Use the settings on the Validate tab of an XML parse rule to specify that Process Commander should
validate the incoming XML stream against a published definition (XSD or DTD) before attempting to
parse it. When you enable validation for a parse rule that calls other parse rules, there is no need to
enable validation on the called rules because the entire XML stream is already validated by the time
the called rule runs.

Specify whether the parse rule should use validation always, or only if a condition specified in a when
rule (Rule-Obj-When) is true. Additionally, specify how Process Commander handles the error:
whether to report errors as page messages on the target page and continue processing or throw an
exception that causes processing to stop.

When a validation exception occurs, Process Commander handles it as follows:

1. ■ If the XML parse rule is used in a service or connector rule data mapping, the
exception is reported as an InboundDataMappingException.
1. - If the exception occurs for a connector rule and you are using an error handler flow
like the ConnectionProblems flow, the exception causes the work object to be routed to
the error handler flow. If you are using the connector activity to handle exceptions,
configure the activity to respond as for other exceptions.
2. - If the exception occurs for a service rule, the outcome depends on the rule type. For
example, for a SOAP service rule, a SOAP fault that contains the validation error is
returned to the SOAP client application.
2. ■ If the XML parse rule is used in an activity (Apply-Parse-XML), the exception is
reported as an XMLValidationException. You can configure the activity to respond to
validation exceptions as you do for other exceptions.
The Schema Description
Process Commander can perform schema validation against either an XSD file or a DTD file:
3. ■ If you select XSD, specify the URL of the XSD file on the Validate tab.
4. ■ If you select DTD, the identity of the DTD file must be provided at runtime in the
incoming XML stream to be parsed. The incoming stream must contain a DOCTYPE
statement that identifies the DTD file to use to validate the stream.

4. Procedural Validations

The Template includes examples of procedural validations for the referring provider and member
information submitted on the Authorization Request. These validations are performed against
sample data instances in the PegaHC-Data-Party-Provider and PegaHC-Data-Party-Member
 classes, respectively. The Template also includes a process to check for potential duplicate
requests.

The intent of these types of validations is to determine if the request is legitimate and worth
processing.

Extension Tip: The current workflows for searching providers and members are placeholders for the
validation process. In production, the integration with the payer's legacy data will involve one of the
other service and / or connector rules.

The Template assumes a single match against the searched data instance. In production, the
workflow should be updated to accommodate situations when multiple matching records are found.

Member Validation
The Template includes a process to validate the member (patient) information submitted on the
Authorization Request. The validation is performed against the sample member data records stored
in the PegaHC-Data-Party-Member class. See Chapter 3, "What is Already Set Up" for the complete
list of sample Member Data.
Figure 4-15 shows the ValidateMember workflow which includes a process to search for the member
by ID and then by a combination of last name, first name, and date of birth.

Figure 4-15. Validate Member Workflow

 The following validations are performed in the ValidateMember workflow.

Validation Reject Reason Code

Patient Not Found 77

Patient Not Eligible 95

The Framework validates the member if the member is active on the requested service date on the
authorization by comparing the service date to effective and term dates on the member data.
Key Rules for the Member Validation Process
Figure 4-16 shows the rules that are used in the member validation process.

Rule Name Rule Type Function

Class: PegaHCPF-Work-AuthorizationRequest

ValidateMember Flow Launches the member validation process

GetMemberDataByID Activity Searches for the member by ID

GetMemberDataByOther Activity Searches for the member by name and DOB

MemberNotFound When Checks to see if a member record was found

MemberIneligibleOnServiceDate When Checks to see if the member is active on the

service date

Figure 4-16. Member Validation Rules

Extension Tip: The current workflow for searching and validating members is a placeholder. In
production, the integration with the payer's legacy data will involve one of the other service and / or
connector rules.

The Template assumes a single match against the searched data instance. In production, the
workflow should be updated to accommodate situations when multiple matching records are found.

Referring Provider Validation

The Template includes a process to validate the referring (requesting) provider information
submitted on the Authorization Request. The validation is performed against the sample provider
data records stored in the PegaHC-Data-Party-Provider class. See Chapter 3, "What is Already Set
Up" for the complete list of sample Provider Data.

Figure 4-17 shows the ValidateReferringProvider workflow that includes a process to search for the
referring provider by ID.
 Figure 4-17. Validate Referring Provider Flow

The following validations are performed in the ValidateReferringProvider workflow.

Validation Reject Reason Code

Provider Not On File 51

Provider is not a Primary Care Physician 49

The Framework validates the Primary Care Physician (PCP) only when the member's plan type is
HMO. The requesting provider ID is matched against the PCP ID on the member data retrieved in
the earlier process.
Key Rules for the Referring Provider Validation Process
Figure 4-18 shows the rules that are used in the referring provider validation process.

Rule Name Rule Type Function

Class: PegaHCPF-Work-AuthorizationRequest

ValidateReferringProvider Flow Launches the provider validation process

GetReferringProviderDataByID Activity Searches for the provider by ID

ReferringProviderNotFound When Checks to see if a referring provider record

was found
Rule Name Rule Type Function

ReferringProviderNotPCP When Checks to see if the referring provider is a

PCP for the member

Figure 4-18. Referring Provider Validation Rules

Extension Tip: The current workflow for searching and validating providers is a placeholder. In
production, the integration with the payer's legacy data will involve one of the other service and / or
connector rules.
The Template assumes a single match against the searched data instance. In production, the
workflow should be updated to accommodate situations when multiple matching records are found.

Duplicate Request Validation

The Template includes a process to validate for potential duplicate requests.
The validation is performed against existing Authorization Requests (instances of PegaHCPF-Work-
AuthorizationRequest).

Figure 4-19 shows the DuplicateCheck workflow that includes a process to search for potential
duplicate records with previously created work objects.

Figure 4-19. Duplicate Check Workflow

Comparison of the following data elements determines if this is a duplicate request:

1. ■ Request Type
2. ■ Requesting Provider ID
3. ■ Member ID
 4. ■ Service Type
5. ■ Service Date
6. ■ Request Status (of Pending)

An item match is only considered if all of the data elements listed above are the same as the current
request. If a single match is found to all of the data elements listed above, the request transaction is
denied, and the following data elements are set:
7. ■ Certification Action Code = A3 (Not Certified)
8. ■ Reject Reason Code = 91 (Duplicate Service)
Key Rules for the Duplicate Request Validation Process
Figure 4-20 shows the rules that are used in the duplicate request validation process.

Rule Name Rule Type Function

Class: PegaHCPF-Work-AuthorizationRequest

DuplicateCheck Flow Launches the duplicate request validation process

LookupDuplicate Activity Performs matching for potential duplicates

Figure 4-20. Referring Provider Validation Rules

4. How to save a work object that fails validation

I have an activity that is invoked via a service. In the service activity, I create a work page, and invoke a
flow. In the flow, I use a utility activity to assign values to work object properties.
At the end of this utility, I want to assure that the work object will successfully save before moving on to
subsequent steps. If it won't, then I'd like to somehow still save this work object so that I can later
examine it to see what went wrong. Are these steps the recommended implementation?
Use Page-Validate to test to see if the object will save successfully.
If stepStatusGood, exit the Utility.
If bad,
do an Obj-Save (deferred, with "with errors" left unchecked)
Taskstatus-Set to return a Fail to the flow
exit the Utility.
The flow will continue (quickly reaching an "end flow", which will return control to my initial activity). The
initial activity will do a Commit, and send a Service Response.

Suggested Approach
The work object database table is not a natural or recommended place in which to log errors. If the
reason you wish to persist the work object despite errors is simply to collect forensic evidence on the
nature of its errors, then we suggest the following alternative approach.
Use a separate class (other than the work object class), into instances of which you persist the xml string
of the data coming in from the service and a snapshot of the XML and its generated page. That way you'll
have all the information in a format that can be digested in a lot of different ways, in a place where saving
it with errors would not be an issue.
For work pages with errors, you'll return to the service the name of data class in which you're capturing
the forensic evidence, and the ID of the instance. For work objects without errors, you'll return to the
service the class and ID of the work object.
If you receive errors upon subsequent service manipulations of already persisted work objects, you can
use the same data class in which to persist the forensic evidence - and in addition capture in that instance
an image of the work object page in XML format.
Alternatively, you could put the forensic evidence into an embedded page for which the "do not validate
embedded pages" value (on Property rule) is specified, and then you could save that flawed page without
actually validating it.

5. How to use regular expressions to validate user input

Regular expressions provide a popular means to search text for a pattern. You can use regular
expressions in edit validate rules (Rule-Edit-Validate rule type) in your application to check the
format of a user input. Because regular expressions can describe a wide variety of text patterns, this
approach can provide improved data validation without requiring your development team to write and test
long Java routines.

Suggested Approach
An edit validate rule (Rule-Edit-Validate rule type) checks the format of a text value, such as a
value typed into a form by an application user. The result outcome is either true — the value does meet
the criteria defined in the rule, or false — the input value is rejected with a message.
In general, Process Commander developers need Java skills to create new edit validate rules. However,
Java includes the well-known pattern matching facility known as regular expressions. This facility, like
the UNIX grep command, tests an input string against a pattern, finding the first match (if any), or all
matches. Using a short Java snippet, an edit validate rule can test an input string against a regular
expression.
Many books, Web sites, and software products explain regular expressions, which are not explained here.
(For the complete, official specification see
http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html. The simple example below illustrates
a Canadian postal code check, but other more complex regular expressions can be tested with very
similar code.
Example: Canadian Postal Codes
Every postal code for Canada consists of seven characters (including a single space) in the format ANA
NAN, where A is a letter and N is a digit from 0-9. The first character is one of 18 specific letters; others
are not so constrained. For example, the Pegasystems office in Toronto is located in Postal Code M5X
1E3.

1. Develop and test the regular expression.

The regular expression [ABCEGHJKLMNPRSTVXY][0-9][A-Z] [0-9][A-Z][0-9] captures the
Canadian Postal Code format. To confirm this:
1. Open the built-in regular expression tester activity Code-Pega-Parse.RegExTester. This
supports the same Sun Microsystems® implementation that the edit validate rule executes.

2. Click the Run toolbar button ( ).

3. Click the Run Rule and Execute buttons. (Leave the parameters blank)
 4. Complete the Regular Expression field. Enter a test string in the Source field.
5. Click Test Expression.

This test case confirms that the source "M5R 2E8" matches the regular expression pattern.

A second test case confirms that D5R 2E8 does not match. D is not one of the allowed first letters.

Note that the tester may find a match as a substring of a longer string:
2. Create the Rule-Edit-Validate rule
Save the pattern you tested. in a scratch text file. Create an edit validate rule that uses the
java.util.regex.Pattern class to apply the pattern to the predefined input variable theValue:

Paste the pattern you tested into the compile( ) method. In this example, the entire Java Source field
contains only a few lines of code:
boolean retval = false;
if (theValue.length() == 7 ) {
java.util.regex.Pattern p =
java.util.regex.Pattern.compile("[ABCEGHJKLMNPRSTVXY][0-9][A-Z] [0-9][A-Z]
[0-9]");
java.util.regex.Matcher m= p.matcher(theValue);
retval = m.matches();
}
return retval;
3. Reference the edit validate rule in an activity or validate rule.
Edit validate rules execute through activities or through validate rules (Rule-Obj-Validate). To
illustrate one use of the Canadian Postal Code, you can override the standard validate rule Data-
Party.WorkAddress, which by default requires only that the property pyWorkPostalCode not be
blank.
Enter "Canadian Postal Code" in the Validate field and an error message (or Rule-Message key) in the
Error Message field.

(For testing purposes, delete the row for the pyStateCode property.)

4. Test
To exercise the validation rule and edit validation rule:
1. Select the File > Open > Work Pool > Sample Work menu item to access the PegaSample
sample application.
2. Select the Run > Process > General Task menu item to enter a General Task
3. In the Parties section of the New form, select Add Party... Customer.
4. Set the Contact Preferences to Work Address. Enter customer details, including an invalid or
valid Canadian Postal Code in the ZIP field.
5. Click Create.

In this example, the invalid code D8K 1Q1 was rejected.

Limitations and notes
 Edit validate rules provide only format checking. Many values that have the correct format (and so
are accepted as input) do not correspond to real Canadian Postal Codes. However, format
checking can detect many input errors, and is always better than accepting input without any
checking.
 The Submit operation for HTML forms strips off leading and trailing spaces. There is no need to
test for them or to match them.
 Your Rule-Edit-Validate Java code should not accept a substring as a valid match.
 WWW and other public sources provide regular expressions for book identifiers (ISBN numbers),
telephone numbers, email addresses, IP addresses, and many other patterns. Of course, you
should test any expression you plan to adopt to confirm that it matches your application
requirements.
 Consult the Help System topic "About the Regular Expression tool" for more information on the
built in testing tool.
 Like Java, the JavaScript language also supports regular expressions, so after you have
implemented and tested an edit validate rule, you optionally can extend validation to the
workstation using the client-side format validation feature and the standard ClientValidation
HTML Property rule.

6.Declarative Validations

The Template includes examples of declarative validation rules for the specific requested services.
These types of validations are intended to automatically approve or deny specific service requests
and achieve
straight through processing where possible. These validations reduce the number of requests that
need to be processed manually.

Extension Tip: Although the template includes only a few examples of these types of validations, the
declarative network described below can easily be extended to include other service types and
increase the rate of straight through processing.
Key Rules for the Declarative Process
Declarative rules provide a way for you to set or restrict property values, dynamically retrieve the
necessary data, and automate the decision of when to perform a process. In the Authorization
Management template, the main flow called ProcessAuthorizationRequest uses declarative rules to
reach an automated decision.

The process begins by validating the member, and referring provider, and checking for duplicates. If
the authorization request passes the member and provider validity screening and the procedural
checks for duplicates, it begins the declarative processing by calling the decision tree
AuthorizationDecision in the PegaHC-Data-Service class. Figure 4-22 shows the decision tree for
AuthorizationDecision.

Figure 4-22. AuthorizationDecision Decision Tree

This decision tree establishes a value for the AuthorizationDecision property (which contains the text
description of the decision) and the ActionCode property (which contains the X12 standard code for
the decision). The decision tree checks the values of the AuthorizationStatus property for each of the
Procedure Lines and sets the overall decision for the authorization.

The AuthorizationStatus values for the Procedure Line are calculated using a declare expression in
the PegaHC-AUTH-Work-AuthRequest class. This expression uses the decision tree called
AuthorizationDecision in the PegaHC-Data-Service class and possibly one of the following decision
trees to establish a value:
1. ■ CardiacRehabDecision
2. ■ ChiroServicesDecision
3. ■ PodiatryServicesDecision

Figure 4-23 shows the decision tree for the CardiacRehabDecision. This decision tree evaluates the
treatment type of the procedure, the diagnosis codes and dates, and the number of requested units
for the service. Similar validations for other specific service requests may include evaluating other
parameters of the request (such as provider’s specialty, member’s age, member’s plan type).

Figure 4-23. Cardiac Rehab Decision Tree

The decision tree rules used in this process uses Function Alias rules that allow the system to
perform more complicated evaluations while keeping the decision tree rules understandable for a
business user. These rules are:
4. ■ DecisionIsInProcedureList (in the PegaHC-Data-Authorization class)
5. ■ DiagnosisInRangeExists (in the PegaHC-Data-Service class)
6. ■ DiagnosisInRangeAndDate (in the PegaHC-Data-Service class)

The Treatment type places ranges of procedures into categories, and it is calculated by a declare
expression in the PegaHC-AUTH-Work-AuthRequest class. The declare expression uses a decision
table called Treatment in the PegaHC-Data-Service class which looks at the Procedure Code and
Treatment Type and then places a procedure into a Treatment category. Figure 4-24 shows the
decision table called Treatment.
 Figure 4-24. Decision Table for Treatment
Declarative Validations for Non-Covered Experimental Treatments
Certain services are considered experimental treatments. The requests for these types of services
are considered non-covered and are denied appropriately. Figure 4-25 lists the treatments and
service codes. If any one of the service codes match, the service is denied.

Treatment Service Codes

Thermography 93740, 93760, 93762

Dynamic Infra-read perfusion Imaging C9723

Surface Scanning and EMG 95860-872, S3900

Spinal Manipulation under Anesthesia 00640, 22505

Figure 4-25. Non-Covered Experimental Treatments

When any of the services above are encountered, they are denied and the following properties are
set on the Response Transaction:
7. ■ Certification Action Code = A3 (Not Certified)
8. ■ Reject Reason Code = 98 (Experimental Service or Procedure)

The work object status is then set to Resolved-Denied.

Declarative Validations for Cosmetic Surgery
Figure 4-26 lists the service codes for cosmetic surgery. If any one of the service codes match, the
service is denied.

Treatment Service Codes

Cosmetic Surgery 11920,11921, 11922, 15775-15776, 15781, 15788-15793, 15828,

15829, 15831, 19140, 19316, 19318, 19325, 19328, 19330, 19340,
19342, 19355, 19357, 19361, 19364, 19366, 19367, 19368, 19369,
Treatment Service Codes

19370, 19371, 19380, 19396 30400-30450

Figure 4-26. Cosmetic Surgery Service Codes

When any of the services above are encountered, they are denied and the following properties are
set on the Response Transaction:
9. ■ Certification Action Code = A3 (Not Certified)
10. ■ Reject Reason Code = 88 (Non-covered Service)

The work object status is then set to Resolved-Denied.

Declarative Validations for Services Not Requiring a Referral
Figure 4-27 lists the services not requiring a referral. These are identified by Service Type Codes or
Services Codes.

Service Service Service Codes

Type Code

Diagnostic X-Ray 4

Diagnostic Lab 5

EKG 93000, 93005, 93010, 93040-42, 93224-27, 93230-37,

93268, 93270, 93271-72

Cardiac Stress Test 93015-18

Echocardiogram 93303-04, 93307-08, 93312-18, 93320-21, 93325, 93350

Joint Aspiration D7870

Figure 4-27. Services Not Requiring a Referral

When any of the services above are encountered, they are denied and the following properties are
set on the Response Transaction:
11. ■ Certification Action Code = No Authorization Required

The work object status is then set to Resolved-Denied.

Declarative Validations for Cardiac Rehab Services
Requests for Cardiac Rehab are approved if the request meets the following validations:
12. ■ Service Type Code = BG
13. ■ Service Provider Specialty = 203BC0100Y or 261QA1903N
14. ■ Service Code In = 93797 or 93798
 15. ■ Diagnosis Code In = 394 - 397.9, 398.91, 410.00-414.9, 424.0-424.3,
425.0-425.9, 427.1, 427.2, 427.41, 427.42, 427.5, V42.1, V42.2, V42.6, V43.21, V43.22,
V43.3, V45.81, V45.82, V45.89, V57.21, V57.89
16. ■ Diagnosis data is not more than 26 weeks old (for example, DATEDIFF IN WEEKS
(Diagnosis Date – Current Date) < 26

If all the conditions above are met, the following properties are set on the work object:
17. ■ Certification Number = Work Object ID
18. ■ If the Request Service Units are = or < 30, the action code is set to A1 (certified in
total) and the Authorized Units are ser to the Requested Units
19. ■ If the Requested Service Units are > 30, the action code is set to A6 (modified) and
the Authorized Units are set to 30
Declarative Validations for Chiropractic Services

Requests for Chiropractic Services are approved if:

20. ■ Service Type Code = 33 OR 34
21. ■ Service Provider Specialty = 111N00000N
22. ■ Service Code In = 99201-04, 81000, 81002, 95831, 95851, 98940-43, 97012, 97014,
97140
23. ■ Diagnosis Code In = 353.0, 353.8, 722.0, 722.10, 722.11, 723.2, 723.3, 723.4, 724.3,
724.8, 729.2, 739.2, 739.4, 739.1, 739.2, 739.8, 846.0, 846.9, 847.0, 847.1, 847.2

If the above conditions are met, the Action Code is set to A1 (Certified In Total).
Declarative Validations for Podiatry Services
Requests for Podiatry Services are approved if:
24. ■ Service Type Code = 93, 94, or 95
25. ■ Service Provider Specialty = 213E00000N
26. ■ Service Code In = 99201-04, 81000, 81002, 95831, 95851, 98940-43, 97012, 97014,
97140
27. ■ Diagnosis Code In = 353.0, 353.8, 722.0, 722.10, 722.11, 723.2, 723.3, 723.4, 724.3,
724.8, 729.2, 739.2, 739.4, 739.1, 739.2, 739.8, 846.0, 846.9, 847.0, 847.1, 847.2

If the above conditions are met, the Action Code is set to A1 (Certified In Total).