Generating Test Data in RAMP Tables

Topics:

This command line tool generates random data in RAMP tables for a given subject. From the OmniServer installation location, run omni.cmd on Windows or omni.sh on Linux, as shown in the following syntax:

>omni.cmd createTestRampData -Dramp.subject=Person -Dramp.batch=1
-Dramp.count=100 -Dramp.withOrphans=yes
–Dgroup.number=20 –Dvalues.file=C:/person-values.properties

where:

ramp.subject

Is required and case-sensitive. It specifies the subject test data to be created.

ramp.batch

Is optional and the default value is 1.

ramp.count

Is the number of records to be generated. The default value is 10.

ramp.withOrphans

Is optional and the default is set to False. If this value is set to yes, y, or true, then orphans will be created.

values.file

Is optional, but it is used to specify values for some fields.

group.number

Is optional, but specifies the number of master records you want the test data to be grouped for the subject. If it is set, the matching field names need to be specified in the values.file.

A generated subject entity has random values for most of the fields. However, there are some exceptions:

More specific instructions for the values to use specific fields may be accomplished by referencing a "values.file".

The following syntax shows a sample values.file.

personaddress.city=Staten Island|New York|Brooklyn
personaddress.zip=10304|10121|11209
person.dob=2018-11-25T15:24:30.294+0400|2016-12-31T8:24:30.005|2017-2-2T3:8:5
person.maritalStatus=source1:set1:value1|source2:set2:value2
person.ssn=

Lists of Individual Values

The fields specified in the values.file option will have one of the values from a ''|'' separated list. The format of date type is listed as person.dob. For the IdsCodeType type, the following should be separated by colons (:), as well as person.maritalStatus:

  • source
  • set
  • value

The "|" separated values will be used sequentially. If the number of the record is larger than the size of the list, then the list values will be reused starting from the beginning.

You can provide the list of values for group matching fields. The number of values should be equal to the number of groups you expect. If the values are not provided for a field, for example, person.ssn=, the tool will use random values for the field and all the records in the same group will have the same value. Therefore, you do not have to specify the values for matching fields if the number of matching groups is larger.

Date Options

The following list describes the date options that are used in testing data in RAMP.

  • Individual Dates. Date value in one of the accepted formats. For example:
    Encounter.ArrivalDateTime=2015-01-01
  • Date Range. Low and high dates that are given. The utility selects randomly from within the range. For example:
    Encounter.ArrivalDateTime=(2015-01-01,2017-10-20)
  • Derived Date. A specified base date and interval. The derived date is computed from the base date and an interval or an interval range. The use case is to compute departure dates which occur after arrival dates.

The format for interval values can be found at:

https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html#parse-java.lang.CharSequence-

Related to ISO-8601, the following examples are offered:

  • PT20.345S -- Parses as 20.345 seconds.
  • PT15M -- Parses as 15 minutes (where a minute is 60 seconds).
  • PT10H -- Parses as 10 hours (where an hour is 3600 seconds).
  • P2D -- Parses as 2 days (where a day is 24 hours or 86400 seconds).
  • P2DT3H4M -- Parses as 2 days, 3 hours, and 4 minutes.
  • P-6H3M -- Parses as -6 hours and +3 minutes.
  • -P6H3M -- Parses as -6 hours and -3 minutes.
  • -P-6H+3M -- Parses as +6 hours and -3 minutes.

Example 1:

Encounter.ArrivalDateTime=(2015-01-01,2017-10-20)
Encounter.DepartureDateTime=[ArrivalDateTime,PT10M]

The departure date is 10 minutes after the arrival date.

Example 2:

Encounter.ArrivalDateTime=(2015-01-01,2017-10-20)
Encounter.DepartureDateTime=[ArrivalDateTime,(PT10M,P4D)]

The departure date is in range between 10 minutes and 4 days of the arrival date.

Code Options

This section describes the code options that are found when generating test data in RAMP.

  • Individual Codes. Codes that are indicated by Source:Set:Value. For example:
    Patient.BiologicalSex=OMNI:0001:M|OMNI:0001:F

    When constructing test data, it is recommended to have codes come from a specific set.

  • Codes from a SourceCodeSet.

    CodeSet is indicated by 'SourceCodeSet':SourceName:SetName and optionally followed by a count. The count is the number of codes from the CodeSet to be used in populating the test data. If no count is specified, then all of the codes in the CodeSet are used. The CodeSet must be populated in the instance model to be used by the command line tool.

    Format:

    SourceCodeSet:SourceName:SetName[,count]

    Example:

    Encounter.HospitalService=SourceCodeSet:OMNI:0069
  • Codes from a SourceCodeMap. You can select codes that are aggregated in a value set. The SourceCodeMap representing the ValueSet must be populated in the instance model to be used by the command line tool.

    Format:

    SourceCodeMap:  SourceCodeMap:SourceName:MapName[,count] (ValueSets Only)   

    Example:

    DiagnosisEvent.Diagnosis= SourceCodeMap:NIH-VSAC:2.16.840.1.113883.3.464.1003.103.12.1001^DiagnosisCode,50  

    This uses 50 codes from the Diabetes Diagnosis codes map.

Link Options

When constructing test data, it is recommended to populate links with actual records in the Omni Model. A count, if provided, is the number of subject instances to be used in populating the test data. If there is no count, then all instances for the subject are used. The records need to already be in the model.

Format:

OMNILINK:Subject[,count]

Example:

Encounter.Patient=OMNILINK:Patient,7

Note: A pool of different sets and codes can be combined for a given field. For example:

ProcedureEvent.Procedure=SourceCodeSet:HLI-V3:2.16.840.1.113883.6.4|SourceCodeSet:HLI-V3:2.16.840.1.113883.6.12|MySource:MySet:ExtraCode
Generate test data in RAMP to test DELETE, REPLACE_ALL, REPLACE_SELECTED, PRESERVE_ON_NULL

A few additional parameters for the createTestData command are introduced to allow even more control over test data generation. The following table lists and describes those parameters.

Parameter

Description

-Dramp.sid 

Specifies the prefix of all sids in the batch. If none is provided, then the sids are randomly generated. This parameter allows you to produce batches of matching resources, but with different randomly generated field values and different batch sizes.

-Dramp.withMissingChildren

The data generator randomly skips a generation of some collection resources. This would allow you to test REPLACE_SELECTED.

Note that not all field values are generated. Some field values are randomly set to null to allow PRESERVE_ON_NULL testing.