An active database map is available for selection in Wanalyzer. Inactive maps are not offered for selection.

A descriptive name identifying the database map.

Defines relationships between columns in different tables, such as Patient.Id = Encounter.PatientId. These relationships support parent–child relationships between layers and are maintained at map level.

Used when a query spans different server groups, for example joining patient data from a hospital database with user data from a mobile database. The cross-server WHERE conditions should be connected with AND. Wtransfer first evaluates the primary rule in both databases, derives the target set from the side with fewer records, and then retrieves the required column values.

Generally, it is more logical to construct the main query from within the same server. It is used in rarer cases—specifically when two databases cannot be consolidated onto a single, shared server.

Optional connection information specifying the Wtransfer endpoint to which Wanalyzer sends requests. If left empty, the Wtransfer instance installed with the WisdomEra platform is used. Remote endpoints can be specified to support multiple available Wtransfer servers.

The Wtransfer endpoint can be a domain name or an IP address with port, for example http://10.101.101.25:8487. Requests are directed to the configured endpoint.

An identifier assigned by WisdomEra for standardized maps and automatic updates. It cannot be edited manually. Maps with a product code have protected layer and parameter definitions, although connection-specific settings, SQL, table and column mappings can be adjusted.

An active database map is available for selection in Wanalyzer. Inactive maps are not offered for selection.

Select the supported database engine/connection module, such as Microsoft SQL Server.

A descriptive server name; it may include the organization and an IP address.

In the Wtransfer application, the same query can be executed across multiple connected servers. For instance, suppose we want to retrieve the patient IDs of male patients with a diagnosis of "X." Since there are two separate hospitals, it is possible for the same patient ID values ​​to appear. If the "prefix" option is enabled in the parameter settings, the code value for that specific source is appended to the query result, connected by an underscore—for example, "Xyz_123," where "Xyz" represents the code.

When a query is sent to Wtransfer, the name of the primary unique layer—referred to as the " main layer "—is also transmitted. The ID of this main layer is known to Wtransfer even before the query begins execution on the servers. Server group assignments are configured within the database map's layer settings; this allows the system to determine which server group the main layer is linked to, as well as the specific list of servers contained within that group. This grouping mechanism is particularly advantageous when a database map involves multiple servers or servers with varying content structures.

For instance, suppose the "Patient" layer is mapped to the "HBYS" (Hospital Information Management System) server group, and our query targets this "Patient" layer. If our map contains five "HBYS" server groups and one "mobile" server group, the query will be executed only across the five "HBYS" server groups—it will not perform any queries against the mobile database.

Optional free-text notes for the map/server configuration.

It serves the purpose of general information and categorization. It has no active function within the system. It can be used when there is a need to group various facility codes together; for instance, hospitals with codes a, b, and c could be assigned to group X, while those with codes d, e, and f could be assigned to group Y. The information regarding groups X and Y is not used in queries.

A server may have replicas, which are essentially copies of that server. When the primary server is updated, the current data is propagated to the other server nodes. Occasionally, server nodes may experience access issues or undergo maintenance. For this reason, access management is handled with these server nodes as the basis.

Active nodes can be contacted; inactive nodes are not tried.

A human-readable name for a server node, such as a hospital name.

Specifies the connection order that the created nodes will follow when establishing connections. For example, replica servers can be prioritized over primary servers. If necessary, the system can be configured so that the primary server is the last one to be connected to.

The IP address used for a connection. An IP or domain is expected; when a domain is configured, it takes precedence.

The domain used for a connection. An IP or domain is expected; when a domain is configured, it takes precedence.

The username used to authenticate to the database server.

The password used to authenticate to the database server. Handle this value as a credential.

Optional connection port, used together with the IP address or domain when supplied.

Free-text notes describing a particular server node.

A database server can host multiple databases. The databases to be used for queries are specified here. In addition to a basic 'dbo' database, other distinct databases—such as those for a Hospital Information Management System (HBYS) or a laboratory (LAB)—can also be configured.

A database group is a field used to categorize database names; it does not necessarily have to be the actual database name itself. In multi-server database maps, databases with identical structures may have different names across different servers.

For instance, a hospital database might be named `hbys_xyz` on "server1," while the corresponding hospital database on "server2" might be named `hbys_abc`. Since these databases share the same structure, this field allows us to group them under a common group name—for example, "hbys."

By "sharing the same structure," we mean that the tables and the columns within those tables are identical. Once a database group name is defined, it is used across various map layers and their associated parameters. The actual database name is never used directly within these parameters or layer settings. Instead, queries are executed by mapping the parameters to their respective database groups.

This corresponds exactly to the name of a database created on a database server. Actual queries are generated by mapping this database name to a database group defined within the map layer and its parameters.

For instance, suppose a database group defined in a layer parameter is named "hbys." In a database map spanning five servers, the actual database names on each server might be "hbys_1," "hbys_2," "hbys_3," "hbys_4," and "hbys_5." To generate valid queries, the system requires the specific database name—such as "hbys_1." By associating the "hbys" group identifier with these individual database names across the servers, the system can easily resolve the correct database name during query execution. When a query is run on the first server, the system identifies that "hbys" corresponds to "hbys_1" and adjusts the query accordingly. In a single-server environment, the database name and the group name may be identical, as there is no need for grouping in such a setup.

An active database map is available for selection in Wanalyzer. Inactive maps are not offered for selection.

The visitor-facing name of the layer, such as Patient or Encounter. Choose a clear domain term because it is used when users browse layer structures and select data in Wanalyzer.

Layers are data units in which data from various tables is collected. Each layer requires a main table capable of generating a unique ID value for its rows.

For instance, patient encounter data can be retrieved from a table named encounter (or "application/request"). Specific columns from this table can be selected; it is not necessary to include every column. Furthermore, a parameter within the encounter layer—such as "appointment type"—can be sourced from a separate table (e.g., an "appointment" table) and mapped to the corresponding parameter in the encounter layer.

The data layer structure here functions by consolidating data from various tables. The role of the main table is twofold: it serves to generate unique row identifiers and acts as the defining element for the parent-child relationships established within the layer tree.

Additionally, the main table selected here must be one of the tables utilized in the table relationships defined within the layer tree settings—found under the general settings of the database map .

When data is received from the layer, the id value in the primary of the data is also taken. Client id actually means the primary singular id value to be used for this layer in the target database. Select yes if you want the server code —specified in the server settings—to be added as a prefix (followed by an underscore) to the primary column ID value.

If you are performing queries across multiple database servers, it is advisable to set the prefix option to "yes," as the same primary ID might exist on different servers. For instance, a record with an ID of 123 could exist at Hospital X, while another record with the same ID of 123 could exist at Hospital Y. To distinguish between them, the system will retrieve the data as "x_123" and "y_123," respectively.

The table used to obtain the layer’s unique client ID; normally the same as the main table.

Client id, that is, the primary unique id value for the layer, can be a direct column value or can be generated with the help of SQL. Because sometimes the direct primary column id may not be designed in the tables. It is used in these situations, albeit rarely.

For example, a unique primary ID value can be generated by concatenating multiple columns. CONCAT( [HBYS].[Order].[Ilac].[OrderId], '_', [HBYS].[Order].[Ilac].[UrunId])

Free-text description or notes about the layer.

Contains the list of layers associated with the parent and child of the layer. Thus, the relationship of this layer with other layers is established. The last element in the list is this layer. The preceding elements refer to the upper layers. For example, the diagnosis layer is added after the other layers have been specified, starting from the top of the hierarchy.

The layer primary column value is usually the same as the client id value. The primary column value is used as a list. Usually there is one primary column in the table. However, in some cases, a row can be uniquely identified by using more than one column. In such instances, multiple columns can be selected as a list. For example, an `Id` column might be designated directly as the primary column. Alternatively, a row in a table might be uniquely identified only when both `x_id` and `y_id` are considered together; in this case, both should be selected.

The selected primary column name within the primary-column list.

If there is more than one primary column, a special character can be chosen to combine them. The underscore _ is generally used for joining.

The group in which the layer is located in the server list is selected here. Of course, first of all, servers must be created and server groups must be added within the servers. This parameter controls which servers can execute a query when it is initiated from this layer.

For example, suppose there are 20 servers in the server list. If we select "HIS" and 15 of those 20 servers are designated as belonging to the "HIS" server group, then any query initiated from this layer will only be processed across those 15 servers.

There may be more than one database on the servers. While servers are defined under the map, database groups are also created. This parameter allows for the selection of a database group from those defined on the servers. You should select the database group that contains the layer's main table.

For example, general patient information might be stored in an "HIS" (Hospital Information Management System) database, while laboratory data might reside in a "LAB" database. This setting determines which database group—within the target server group—should be used to execute queries related to this layer.

When the data is queried by Wanalyzer, if the data with the same id value is desired to be a single row after data is received from more than one server, then it is specified as yes. In this case, the prefix setting should be set to "no." This is because the unique ID value for a row within a layer must be consistent across all other servers; this is a concept applicable to centralized ID systems.

For example, consider data being collected from 10 different hospitals, where a national identification number serves as the unique identifier—acting as the primary ID. In this scenario, the system consolidates data from the various hospitals into a single row based on this ID. Consequently, data from all hospitals appear in a single row within the Wanalyzer datasets. While a specific laboratory test result might otherwise be stored across different hospital servers, it is consolidated into a single row and cell within the Wanalyzer dataset. Note that because this configuration involves a data deduplication process, some performance slowdown may be observed.

Usually the same as the primary column value. When managing queries, the line point where the query remains is managed with this value. In other words, it is also used as an offset column. The mechanism for resuming from a specific point is managed using this column. In some cases, multiple columns may be required—much like with the primary column—to ensure uniqueness and handle the offset process. In such scenarios, the offset columns are added as a list, structured in a way that guarantees uniqueness.

The column name selected as an offset field.

It is used when you want to create an absolute filter in the layer query.

For example, if we never want to retrieve those whose status is canceled in a reference layer, We can specify it as `[HBYS].[Patient].[Application].[State] IN ('0')`. In fact, the query is generated by appending this to the `WHERE` clause.

An active database map is available for selection in Wanalyzer. Inactive maps are not offered for selection.

The name of the parameter is its value. It should be designed using English characters without spaces. When multiple database maps are used in a Wanalyzer project, parameters with the same name within layers that also share the same name will produce identical query outputs.

When a query with more than one server is appropriate, the prefix value indicating that there are different servers can be added to the beginning of the parameters coming from the query.

For example, the hospital code is IST in Istanbul hospital and IST in Ankara hospital. Let’s assume the code is ANK. Data is retrieved as IST_123 from the server with the code IST, and as ANK_123 from the server with the code ANK. This can be used when a parameter is intended to be presented as a unique, singular value.

If the parameter content will be a column of a table, table selection is made here. If parameter data will be taken directly from the main table, the main table value can be selected. This table name does not necessarily have to be the primary table of the layer. If data is to be retrieved from a table other than the primary one, a join relationship must be established between the primary table and the specified table. This join configuration is defined within the "Join SQL" parameter.

For instance, let the "Patient" (Hasta) layer be defined based on the `[Hasta]` table. Suppose we want to retrieve the "SMS communication consent" parameter from a related table—`[hastaizinler]` (patient consents)—and add it as a parameter to the Patient layer. In this case, the table name would be `[hastaizinler]`, and the `smsizni` (SMS consent) column from that table would be specified as the column name parameter. Furthermore, the `Id` in the `[Hasta]` table must be joined with the `HastaId` in the `[hastaizinler]` table. A join configuration such as the following should be defined in the "Join SQL" parameter: `LEFT JOIN [HBYS].[Hasta].[hastaizinler] WITH (NOLOCK) ON [HBYS].[Hasta].[hastaizinler].[State] = 1 AND [HBYS].[Hasta].[Hasta].[Id] = [HBYS].[Hasta].[hastaizinler].[HastaId]`. Consequently, once the patient ID is obtained from the primary row in the `[Hasta]` table, the corresponding SMS consent status for that patient can be retrieved from the related consent table.

Column that provides the parameter value.

If this parameter is the historical parameter of the layer, then it is specified as yes.

For example, when the laboratory layer is designed, the results of the laboratory parameters are also included. A historical parameter is defined. Selecting "yes" designates a specific historical parameter to represent the laboratory date for the entire layer. There must be exactly one such parameter for the entire layer.

If the data content received from the database is json in object format, then the key value in the json is specified here. Thus, once the data has been retrieved, the information corresponding to the relevant key is obtained.

For example, data from a database cell might arrive in this format: {'pain': 'yes', 'treatment_note': 'xxxx yyyy'}. Here, the JSON key could be 'pain' or 'treatment_note'.

If the data content received from the database is json in object format, then the key value in the json is specified here. Thus, once the data has been retrieved, the information corresponding to the relevant key is obtained.

For example, data from a database cell might arrive in this format: {'pain': 'yes', 'treatment_note': 'xxxx yyyy'}. Here, the JSON key could be 'pain' or 'treatment_note'.

Field name used by supported structured JSON formats. For format 7, it identifies the named child collection that Wtransfer should read; the value must match the structure stored in the source column.

When the database cell content is json, a frequently used json content format determined directly, the format selection can be made to get the relevant data key region. If the target content matches these JSON formats, you can proceed by selecting one of the available formats. When selecting a format, the `json_field_name` must also be defined in accordance with that format.

format_2: [{"values":[xxx]}]

format3: [{"values":[{"value":"xxx"

format4: [{"values":[xxx]}]

format5: [{"values":["xxx"]}]

format6: [{"values":[{"value":"xxx"

format7: [{"children":{"' + json_field_name + '":[{"values":["xxx"]}]}

When the server group is the server group belonging to the layer in which the parameter is located, there is no need to make any definition.

If, during a query on a target server, a parameter specifies a different server group, the system iterates through all servers associated with that specified server group in the database map, queries the targeted data, and adds it to the data list.

For example, suppose the server group for a given layer is hbys . If, while processing the hbys servers, a parameter specifies a different server group—such as mobile —the data is instead queried from the servers defined under that mobile server group. This is a relatively uncommon configuration. If a design requires connecting to a different server group, the table names, column names, or SQL fields must be defined in accordance with the table structures present in those target server groups.

The layer parameter is usually chosen as a column of a table. Sometimes a direct table may not have a column. Data can also be retrieved by constructing specific SQL queries—such as using `CASE` statements or other custom logic—to obtain parameters. In this approach, the table and column name fields are left blank, and a `SELECT` SQL statement is provided instead. The value of this `SELECT` SQL statement should consist of the text that would typically appear between the `SELECT` and `FROM` clauses of a standard SQL query.

For example, you can retrieve the Code information from the Hospital table by constructing a `SELECT` SQL statement like this: `(SELECT [HIS].[dbo].[Hospital].[Code] FROM [HIS].[dbo].[Hospital] WITH (NOLOCK) WHERE [HIS].[dbo].[Hospital].[Status] = 1)`. This SQL text is then inserted between the `SELECT` and `FROM` keywords to execute the query.

When the select sql text is produced, the same sql information is usually added here so that the same parameter can be queried in the where query. This is because a value retrieved via a `SELECT` statement—defined between the `SELECT` and `FROM` clauses—is then utilized within the `WHERE` clause of the query.

For example: `(SELECT [HBYS].[dbo].[Hospital].[Code] FROM [HBYS].[dbo].[Hospital] WITH (NOLOCK) WHERE [HBYS].[dbo].[Hospital].[Status] = 1)`. In this instance, a `WHERE` condition is constructed using the codes for the Istanbul and Ankara hospitals.

The type of the column in the database is selected here. Otherwise, it can be left blank.

WisdomEra parameter type, independent of the database-native type.

Logical database group used to resolve the parameter’s source database. If left empty, the layer database group is used. Set it when the parameter must read from another structurally mapped database group.

Identifies a specific server node when the parameter source cannot be resolved only through the server group. The value is retained by the system after selecting the server and should refer to a server already present in the database map.

Defines which stored value represents true for a bit-like column. For example, choose 1 when the source stores 1 for true and 0 for false; match the setting to the actual database convention.

Defines the JOIN used when a parameter reads from a table related to the layer main table. For example, a Patient layer can read SmsPermission from PatientPermissions with LEFT JOIN PatientPermissions ON PatientPermissions.State = 1 AND Patient.Id = PatientPermissions.PatientId. Use complete table references and conditions that produce the intended single-row relationship.

For parameters with options, this determines how a categorical value retrieved from the database is converted into a label to be displayed to the user. For example, mapping the value '1' to the label 'Female' is handled using one of these methods.

                          
                            SELECT
                            

                          
                             Patient.GenderId,
                          

                             Gender.Name 
                          
                            AS
                          
                          label
                          
                            FROM
                          
                           Patient
                          
                            LEFT JOIN
                          
                           Gender 
                          
                            ON
                          
                           Gender.Id = Patient.GenderId
                          
                            WHERE
                          
                           Patient.Id = 
                          
                            '12345'
                          
                        

It is used in select type parameters. If the option value is to be connected to a different database and retrieved, then the database group is specified. If no database group is specified, the parameter's database group is used as the target database. For instance, while the database group for a parameter might be HIS, the option values ​​for that parameter could be retrieved from a different database named LOOKUP.

It is used for parameters of the "select" type—that is, those offering a choice of options. It is employed when the values ​​for these options are to be retrieved from another server.

It is used for parameters of the "select" type—that is, those with options. It represents the "value" of an option; in other words, it is the unique ID value for that option.

Table containing the option lookup records. Specify the schema-qualified table name.

It is used for parameters of the "select" type—that is, those offering a choice of options. It is employed when the values ​​for these options are to be retrieved from another server.

It is used in select type parameters. If the option type is in 'parameter query after' mode, this parameter is filled if necessary. If you need to retrieve a specific row—such as one where a 'state' column indicates it is active—from the table containing the label value, you can define that condition here using a `WHERE` clause. This is optional.

It is used in select type parameters. Options are available when retrieving from another server. It is not mandatory. It can be used for general informational purposes to indicate a server name.

It is used in select type parameters. It is not mandatory. If the option type is set to 'query with parameter' mode, the label is retrieved by performing a join with the target lookup table using the value obtained from the parameter. In some cases, an additional join may be required; this field is used for that purpose.

It is used for parameters of the "select" (choice-based) type. It specifies the column from which the label value for an option is to be retrieved. Most commonly, these label values ​​are obtained by providing the name of the table containing the options and the specific column that serves as the option label.

It is used in select type parameters. When multiple columns are used as option labels instead of a single standard column from the table, the query text to be added to the `SELECT ... FROM` statement is specified here.

This is used for parameters of the "select" (option-based) type. Options are added and managed via the option list management table. For option types that are in database-mapping mode, a database mapping must also be configured.

When the option list type is of type with parameter query , it needs to be updated in the option list layer parameter from the servers in the database map. Wtransfer automatically connects to the servers to update parameter options. Consequently, if any new options have been created, they appear within the parameter options—and by extension, in the sections of Wanalyzer where query rules are defined—making them available for use. This mechanism is not used during the actual creation of a data query, and it is not mandatory for an option to be predefined; however, if it is defined, the list of parameter options is updated automatically. When creating the query, the option's ID value must be defined as ' value ' and its label as ' label ' using the 'as' syntax.

For instance, when a new test is added to the laboratory test list within a hospital database, this SQL query retrieves the new test and adds it to the parameter's list of options. As a result, this new test value becomes visible among the parameter options when constructing a query in Wanalyzer.