Subject: RE: DGR definition tables
From: Järveläinen Jussi <[email-masked]>
To: Ketevan Goginashvili <[email-masked]>, Talvio Tuomas <[email-masked]>
Cc: Mariam Darakhvelidze <[email-masked]>, Mikheil Dundua <[email-masked]>, Mariana Mkurnali <[email-masked]>, Kahur Kristiina <[email-masked]>, Serpola Pekka <[email-masked]>, Sopo Belkania <[email-masked]>, Ekaterine Adamia <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Lasha Nikola <
Date: Wed, 15 Aug 2018 13:19:48 +0000

Hello!

Nice to hear from You after summer.

Our answers below.

Best regards,

Jussi

From: Ketevan Goginashvili

Sent: 15. elokuuta 2018 14:22

To: Järveläinen Jussi ; Talvio Tuomas

Cc: Mariam Darakhvelidze ; Mikheil Dundua ; Mariana Mkurnali ; Kahur Kristiina ; Serpola Pekka ; Sopo Belkania ;
Ekaterine Adamia ; [email-masked]; [email-masked]' ; [email-masked]; [email-masked]; [email-masked]; 'Lasha Nikola'

Subject: RE: DGR definition tables

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 1st 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 1st 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 1st code in in the order (or the 1st and 2nd,
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

Ketevan Goginashvili, MPH

Head of Health Policy Division

Health Care Department

Ministry of Internally displaced Persons

from  Occupied Territories,

Labor, Health and Social Affairs

144 Tsereteli Ave

Tbilisi 0119, Georgia

Tel: +995 32 251 00 38 ext 1108

Mob: 995 577717984

From: Järveläinen Jussi [mailto:[email-masked]]

Sent: 09 August, 2018 16:50

To: Ketevan Goginashvili

Cc: Mariam Darakhvelidze; Mikheil Dundua; Mariana Mkurnali; Kahur Kristiina; Serpola Pekka

Subject: RE: DGR definition tables

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