- Codes must match to codes used this Georgian DRG version. We do not provide testing tools for testing this. If there are for example some DRG you have not provided a name, then empty name will result in output. DRG code is displayed of course. At the end the mail you’ll find list of tables from where you can find codes that must be included.

- File encoding must be Unicode UTF-8. Attached a sample file (UNRELATED TO ACTUALLY THIS DRG VERSION, just a technical example, these are not actual DRG names).

This renders as follows in VisualDRG limited test. (MDC 00 name is in Latvian because this test in done on top of Latvian version, that is closest to Georgian version.) Provide MDC names in Georgian to translate this.

- All the codes are given with all punctuation characters removed, for example “A001” not “A00.1”. Do not include &, +, * or # characters. Names cannot include commas or double quotation (must be converted as required before importing the file).

Note that other parts cannot be localized to Georgian at this time. All VisualDRG menu texts, buttons, application information and error messages, users’s guide and upper hierarchy levels in diagnosis and procedure code finder helper functions remain in English.

Thus, you need to provide the following classifications as text files as specified above, for the names You wish to have in Georgian. Use file names matching table names but with TXT ending (ie. DRG.TXT,…)

- DRG (you’ll find the DRG codes required to be included in the text files, in table: drgnames.dbf in column: DRG in the dBase DBF file set you have got from NCC)

- MDC (mdc.dbf DGCAT)

- RTC (rtc.dbf CODE)

- Diagnoses ICD-10 (icd.dbf CODE)

- Procedures NCSP (csp.dbf CODE)

If possible, send first some test files even if you have not the whole set.

Best regards,

Jussi

Hello!

Nice to hear from You after summer.

Our answers below.

Best regards,

Jussi

Dear Jussi,

We will send you ICD, NCSP and DRG groups name in Georgian and of the next week. Also about test data, It and UHC department ask you send us again format of test data and detail definition of this format.

>Are you using Cyrillic alphabet of Unicode like sylfaen?  

We have used only ISO 8859-1 character sets and this is in principle a technical requirement.

We can examine what to do and can provide more details, when we have some files for DRG names or ICD-10 names (code, name) from you. Feel free to provide some alternative files for out testing, if possible. This may require some extra work as it may be impossible to update Cyrillic alphabet names in DRG logic source tables, that are dBase tables (drgnames.dbf, icd.dbf and ncsp.dbf). We’ll return to this question with estimated potential extra work when we have the files from You.

We will send you information about contract on Monday.

Also I send you IT departments questions:

-         According documentation there are three possible requestor (like VisualDRG, WebAPI and File Grouper) to database which should be provided from your side for setting up DRG. Should we consider that database for all of them (VisualDRG, WebAPI and File Grouper) and should it be located in one physically server.

It's up to you to set up a database or other system for generating input data for DRG grouper. The data sources can be common or separate, same or different server, depending on how You would like to use the software. The grouper software are not fixed to one particular system architecture but it depends on your local needs what to install and where, from where to get input information and to where to put output information etc.

·         VisualDRG can be used totally off-line not connected to any data source. As an option you can import data files (limited size) if you need to, for example for training or demo purposes.

·         Web API is fed by REST (http requests), you do not actually need any DB.

·         Batch file grouper uses a text file for input data, this no DB actually needed here. Of course in practice (and most of our Nordic customers) store patient encounter data in DBs in their patient systems, but as said, it’s not a requirement.

-         In ‘DRG Grouping’ section, we have ‘Revenue’ field. How this value is calculated?

In VisualDRG Revenue field results in from a simple (DRG weight) x (price of DRG point) calculation. You can set in VisualDRG settings that one DRG point is let’s say 1000 Georgian dollars. You can import a weight table that defines DRG weight for each DRG code, if you have such. Import function is included in VisualDRG. This feature is used by some Nordic users, not all, and it’s an option. it’s up to you to decide if You wish to use this feature and if you wish, you need to put DRG price for weight 1,00 in VisualDRG settings and import DRG weight table. File format for DRG weights is documented in VisualDRG user’s Guide.

-         In software price list, ‘VisualDRG’ does not have version. Do you mean Professional or Standard?

We refer to Professional version here.

-         Should we have possibility to use Georgian user interface in ‘VisualDRG’. If so, what are the instruments that we should use for translations?

VisualDRG interface is in English. We do not provide Georgian translation option at this point. We may consider it later but first we need to get this configured with the English UI. There may be issues with Cyrillic alphabet also here.

-         Does ‘VisualDRG’ support Windows 10 (both x86/x64)?

Yes.

-         In previous email we asked regarding Main and Secondary diagnosis in web API. How can we pass diagnoses so your system can separate and recognize main and secondary diagnoses?

Diagnoses are provided as a string in ordered list. The 1^st diagnosis code in the list is always the main diagnose.

-         In our ICD10 classification system asterisk-dagger codes are little part of whole list of the ICD10 codes.

o   How can we pass those pairs to Web API? How will the Web API distinguish those pairs?

Each dg contains two codes.

o   Is there the same 20 x 2 diagnoses and 20 procedures limit in Web API as is in Visual DRG Grouper file (Appendix C)?

Yes.

o   Are there different instructions for passing asterisk-dagger and other (no asterisk and no dagger)  ICD10 codes to the Web API?

See above. We will provide examples with the documentation about using pairs. This is possible.

o   What is the instructions for writing nonasterisk and nondagger ICD10 codes to Visual DRG Grouper file (Appendix C)?

Put codes in positions 1, 3, 5,… (ie. use odd positions only). For example main dg = N20.1, secondary dg = K21.0. No asterisk-dagger coding is used. Put in input diagnoses: N201,,K210,…

-         Do we have Unicode (utf8) support in VisualDRG, WebAPI, File Grouper and their database? In our case, it is critical because all data tracked in our systems and databases are in utf8 format.

In VisualDRG we need to test this when you have sent the files for DRG names, ICD-10 names and NCSP names (code + description).

-         We already have document „Prodacapo_Grouper_REST_API_general_description.pdf„ for web API. Should we consider methods and parameters given in document as a latest version or you are going to provide updated one with ‘VisualDRG Setup Kit’ (as you mentioned it previous mails)?

We will provide a new version or REST API description. There are no significant changes.

-         According your request to provide test data, we recognized that you are asking us indicate Actual cost of the case. As we clarify given, information is not requested to generate DRG code. In that case, what is the main purpose of this field?

Actual cost is just for reference and it can be displayed side-by-side with DRG calculated revenue. If you hava a patient level costing system you could have this. Put this to zero (0). We also provide patient and service level costing software separately (Prodacapo Costing).

-         In ‘Appendix C: File format for DRG case data’ description, what is the relation among diagnoses and procedures fields? Are there any strict rules to put related piers of diagnoses and procedures in same logical positions?

You may order diagnosis and procedures however you wish. DRG logic internally examines what dgs and procedures are or are not related, in relation to DRG grouping logic. Only ordering requirement is to put main diagnosis in the 1^st position.

Also, is there any rules to indicate that some diagnoses are Main and other should be considered as secondary?

In NordDRG logic system there can be just one main diagnosis. It’s put as the 1^st code in in the order (or the 1^st and 2^nd, if it is a pair).

-         In “Prodacapo_Grouper_REST_API_general_description.pdf” document the response  of https:///evdrgwr/api/v1/drg API method contains “genderFlags, ageFlags, dischargeStatusFlags, lengthOfStayFlags, diagnosesFlags and proceduresFlags”. What do these fields mean?

Those are return fields that provide additional optional information about input variables. You may or may not use those. Flags tell if input variable is considered to be technically correct, is used in DRG grouping logic and if it has caused so called CC (=”complications or comorbidities”) in this case by DRG logic. Flags are used and shown in VisualDRG (color coding). Flags are not output from batch grouper. Flags are returned by REST API.

Attached a sample file: VisualDRG demo data file (=demo and test file format we need to be included in VD Setup kit and for us to do some minimal testing with the grouper with actual Georgian data sets). Thus, please produce similar file with data that can be used in this context (ie. anonymized or randomized in such a way that patient data security is not compromised). File format is documented in VD User’s guide.

Thank you in advance,

With best regards,

Keti

Hello!

Now descriptive texts for diagnoses and procedure in the tables are in English.

Is that OK for you? Those texts will be used in VisualDRG only as helper texts when entering diagnosis and procedure codes and do not affect anyhow actual grouping results.

If you wish to have diagnosis and procedures in VisualDRG in Georgian language, we need those texts in files (Excel with code and texts in separate columns). Those may require extra work from us (Cyrillic alphabet) but we do not know before we test those.

Also, could You provide a test data file to be used for our testing and to be included as a demo data file in VisualDRG setup kit.

Best regards,

Jussi