Hello!
>Thank you your mail. We are talking to Martti, regarding final definition tables and he will contact with you.
Ok, fine, I’ll wait Martti to contact us or I’ll contact him.
>I am sending you IT-s
technical questions:
>“First of all, we would consider to have more detailed documentation
about grouper REST API. Is that document latest version? >Given
‘Prodacapo_Grouper_REST_API_general_description.pdf’ document does not provide enough details.
This is the latest document but we’ll extend the documentation (including information for the questions below) in the version we’ll deliver then to you
with the software setup kit.
All the details are not dependent on the grouper software as such but depends on the definitions. That’s why the software manual cannot describe all the
details because it is common to all different (country and year) DRG versions.
>For example, in the ‘Run grouping for one encounter’ section, request body contains parameter ‘diagnoses’.
> Do we mean
ICD (or something other classifications used in Georgia) and if so what is the version?;
ICD-10 diagnosis system is used in NordDRG.
When using Georgian version of NordDRG, then potentially localized ICD version of Georgia is used.
All the countries using NordDRG have localized version of ICD. There are minor differences between Finnish and Swedish ICD-10 system, for example. The
ICD version that is used in input data must match the version used in grouper version.
There can also be annual versions of ICD as there may be annual versions DRG groping rules, for supporting annual changes in diagnosis codes or modifications
or fixes in the grouping logic, as required. For all current NordDRG countries one annual production version is created.
>o "diagnoses":
"S060, G819",
- which one is main diagnoses;
Diagnoses are given as ICD-10 diagnosis pars: asterisk code of the main diagnosis, dagger code of the main diagnosis, asterisk code of the secondary diagnosis,
dagger code of the secondary diagnosis, … . If you do not use (at least not in all cases) pairs, then give just the 1st code and leave the other empty. We’ll clarify this in the next version of the API document, that will be delivered to you when
we deliver the software.
>o Should
we always use last level from classification hierarchy? for example: G819 = G81.9 or we can pass G81 as a parameter which is one level higher;
You must always use the last, most detailed level and code. For example using G81 is interpreted as an unknown diagnosis code.
For example (in Estonian version but functionality is similar in all versions).
G819 results in DRG 012 (a valid DRG).
G81 results in DRG 470 (DRG errors group)
> What are the
methodology of ‘lengthOfStay’ calculation and measurement unit;
> What is the rounding logic of one day in ‘lengthOfStay’ (in
our case tracking are done hourly bases? For example, 47 hours are considered as 2 days of ‘lengthOfStay’ or 1day)?
LOS is in days, calculated from admission date and discharge date (calendar), w/o time (clock). 47 hours is 2 days.
1=admission and discharge during the same day (outpatient visit for example, there may be special case to use 0 but this depends on the version and will
be clarified by Martti when this version is ready, how to use in the GEO version).
2… = number of days hospital stay, for example 1.7.2018 – 3.7.2018 = 3 days stay, independently of the (clock) time.
>There are also more questions
similar to already mentioned, that’s why we should have more detailed information.
Let us know the other questions when you have those. Some answers depend on the actual DRG logic, to be maintained by Martti Virtanen.
>We’ll prepare a signed (by our CEO Kari Lappalainen) contract.
Mr. Tuomas Talvio (Account Manager) will send the contract on Friday, this week.
>And we will send you file with test patient cases.
Test file must be prepared and ready in standard format. See appendix C in the attached VisualDRG manual.
You’ll also have an example file attached. Prepare your test data in equal format. This file is also VisualDRG demo file.
Number of cases is not very important but some hundreds … 10000 at most, would be ok.
Please note that this test file is just for our technical testing (codes are valid etc.), not for testing the actual DRG logic, how it works.
You must agree on with Martti about the actual DRG logic test cases as required.
>Thank you,
>with best regards,
>Keti
Best regards,
Jussi