TARDOC Bill creation / transmission: Difference between revisions

From Kordeus Wiki
Jump to navigation Jump to search
Stefanseiler (talk | contribs)
No edit summary
Mionamilosevic (talk | contribs)
No edit summary
Line 5: Line 5:
!ToDo
!ToDo
!Definition of Done / Acceptance Criteria
!Definition of Done / Acceptance Criteria
!Comment
|-
|-
| rowspan="6" |
| rowspan="6" |
Line 14: Line 15:
* Automatically end consultation timer on end
* Automatically end consultation timer on end
* The logic of works on the consultation time tracking
* The logic of works on the consultation time tracking
|
|-
|-
|Extend current version of Kordeus:
|Extend current version of Kordeus:
Line 29: Line 31:
* Timer stops on being more than 30 minutes inactive
* Timer stops on being more than 30 minutes inactive
* Starting the  
* Starting the  
|<u>Doctors</u> can not edit anything in the form without having started the examination timer TBD depending on the encounter
|-
|-
|Create ICD-10 catalog to incorporate in the system
|Create ICD-10 catalog to incorporate in the system
|
|
* We have a searchable catalog (fulltext search) in some service, which can be searched realtime
* We have a searchable catalog (fulltext search) in some service, which can be searched realtime
|Please send it
Free text diagnoses?
Are diagnoses related to services?
|-
|-
|ICD-Rule-Editor
|ICD-Rule-Editor
|
|
* The admin can create rules, which encounter data drives which ICD-10 diagnose with Tiggerconditions (AND OR connected) and a resulting ICD-10 Diagnose
* The admin can create rules, which encounter data drives which ICD-10 diagnose with Tiggerconditions (AND OR connected) and a resulting ICD-10 Diagnose
|Can you stop a diagnose, can you delete it?
What happens with previous diagnoses, they are related to the patient not enc.
|-
|-
|Service Detection Rule Editor
|Service Detection Rule Editor
Line 42: Line 50:
|
|
* The admin can create rules, which encounter data drives which LKAAT position with Tiggerconditions (AND OR connected) and a resulting ICD-10 Diagnose  
* The admin can create rules, which encounter data drives which LKAAT position with Tiggerconditions (AND OR connected) and a resulting ICD-10 Diagnose  
|
# This can be done if the all rules are added manually, search service add rule for it and save it
# What happens with the new version of catalogue?
|-
|-
|Encounter ICD-10 qualifikation
|Encounter ICD-10 qualifikation
Line 72: Line 83:
* Diagnoses can be added manually by text search and speicificatin of state and location
* Diagnoses can be added manually by text search and speicificatin of state and location
* Diagnoses are adopted from last encounter (with button-states which are adopted as well)
* Diagnoses are adopted from last encounter (with button-states which are adopted as well)
|What happens with old diagnoses?
Encounter does not have a diagnoses patient does
|-
|-
|Mid October
|Mid October
| colspan="3" |Golive in IROC of ICD-10 qualification and time-tracking
| colspan="3" |Golive in IROC of ICD-10 qualification and time-tracking
|
|-
|-
|30.09.
|30.09.
Line 81: Line 95:
* Download and provide to Goran
* Download and provide to Goran
* 30.09. is the official publish date of TARDOC LKAAT catalog json, we need to form a catalog
* 30.09. is the official publish date of TARDOC LKAAT catalog json, we need to form a catalog
|
|-
|-
| rowspan="5" |
| rowspan="5" |
Line 89: Line 104:
* Admin sees all service, which can be detected
* Admin sees all service, which can be detected
* Admin can create edit, rules by this schema:  (1) LKAAT positions and  (2) materials are created out of a detected service
* Admin can create edit, rules by this schema:  (1) LKAAT positions and  (2) materials are created out of a detected service
|Materials TBD, handed out, consumed? They are currently products and will be billed as WAR as they come from different catalogues.
|-
|-
|Billing preparation screen
|Billing preparation screen
Line 97: Line 113:
* LKAAT positions can be added / removed manually
* LKAAT positions can be added / removed manually
Please note, that all encounters till 31.12.2025 must use the old Billing-Flow, Encounters from 01.01.2026 must use the new billing flow
Please note, that all encounters till 31.12.2025 must use the old Billing-Flow, Encounters from 01.01.2026 must use the new billing flow
|TBD
|-
|-
|Billing creation flow
|Billing creation flow
Line 104: Line 121:
* Use CaseMaster, Grouper and Mapper to get bill.xml
* Use CaseMaster, Grouper and Mapper to get bill.xml
* Display the bill in the UI
* Display the bill in the UI
|Grouper and mapper jsons do not exists. Ther are functions in TARDOC matcher.
Understanding of the logic is off.
|-
|-
|Bill upload
|Bill upload
Line 110: Line 129:
*Bill can be clears the bill for upload
*Bill can be clears the bill for upload
*Bill is uploaded and visible in Medidata Transport syystem
*Bill is uploaded and visible in Medidata Transport syystem
|First two points have to be reviewed, on sign the date is set.
This would obsolete draft bills then.
|-
|-
|
|
Line 118: Line 139:
* We have a fresh fully running Kordeus integration environment which is not identical with the current envirnment, which we need to other tasks testing. This needs to be independent and only for TARDOC testing
* We have a fresh fully running Kordeus integration environment which is not identical with the current envirnment, which we need to other tasks testing. This needs to be independent and only for TARDOC testing
* In the Test environment of Medidata (Seiler IPR AG - Webservice 1) we can upload files from Kordeus Integration
* In the Test environment of Medidata (Seiler IPR AG - Webservice 1) we can upload files from Kordeus Integration
|Who is responsible for setting up this?
|-
|-
|Mid November
|Mid November
| colspan="2" |Deployment on integration enviroment
| colspan="2" |Deployment on integration enviroment
|Testing and refinement by Marco
|Testing and refinement by Marco
|
|-
|-
|12.12.
|12.12.
| colspan="2" |Doctors training on integration environment
| colspan="2" |Doctors training on integration environment
|
|
|
|}
|}

Revision as of 10:17, 16 September 2025

Desired Dates Milestone ToDo Definition of Done / Acceptance Criteria Comment
KORDEUS Prerequisites for TARDOC AppointmentType-Admin Each milestone block shows two checkboxes:
  • Automatically start consultation timer on start
  • Automatically end consultation timer on end
  • The logic of works on the consultation time tracking
Extend current version of Kordeus:

Consultatation time tracking

  • Doctors can not edit anything in the form without having started the examination timer
  • If the encounter is already signed, the doctor can press the "Start-Timer" again, which re-opens the timer
  • Other users can edit anything at any time
  • Doctors can not leave the form without having stopped the examination timer
  • Doctors can only have one examination timer running at the same time. This is checked with the database, so no concurrent timers of patients with the same doctor can run at the same time
  • In the encounter we see the total working time of the doctor with this encouter, with mutiple fraction (10:05 - 10:12, 10:40 - 10:42) on hover on some icon. When clicking it, you go to a screen where you can editing these timings. (add, delete, manipulate). Changing shall be documented from prooving against 3rd parties.
  • Timer stops on leaving the encounter (regular leave)
  • When the doctor accidentally closes the browser, the timer is stopped preclose
  • Timer stops on being more than 30 minutes inactive
  • Starting the
Doctors can not edit anything in the form without having started the examination timer TBD depending on the encounter
Create ICD-10 catalog to incorporate in the system
  • We have a searchable catalog (fulltext search) in some service, which can be searched realtime
Please send it

Free text diagnoses? Are diagnoses related to services?

ICD-Rule-Editor
  • The admin can create rules, which encounter data drives which ICD-10 diagnose with Tiggerconditions (AND OR connected) and a resulting ICD-10 Diagnose
Can you stop a diagnose, can you delete it?

What happens with previous diagnoses, they are related to the patient not enc.

Service Detection Rule Editor

(optional)

  • The admin can create rules, which encounter data drives which LKAAT position with Tiggerconditions (AND OR connected) and a resulting ICD-10 Diagnose
  1. This can be done if the all rules are added manually, search service add rule for it and save it
  2. What happens with the new version of catalogue?
Encounter ICD-10 qualifikation
  • A encounter can not be signed without at least one ICD-10 Diagnose to defined at the encounter
  • In diagnose buttons are clicked in documentation the appropriate diagnoses are added to the encounter diagnose list and visible with Code, Name, State and Location according to ICD-Rules.
Kürzel Bedeutung Typischer Einsatz
V Verdacht auf Verdachtsdiagnose, noch nicht gesichert
G gesicherte Diagnose endgültig bestätigte Diagnose
A Ausschluss Diagnose wurde ausgeschlossen
Z Zustand nach z. B. Zustand nach Herzinfarkt
  • Diagnoses can be added manually by text search and speicificatin of state and location
  • Diagnoses are adopted from last encounter (with button-states which are adopted as well)
What happens with old diagnoses?

Encounter does not have a diagnoses patient does

Mid October Golive in IROC of ICD-10 qualification and time-tracking
30.09. Import LKAAT catalog into system
  • Download and provide to Goran
  • 30.09. is the official publish date of TARDOC LKAAT catalog json, we need to form a catalog
Integration environemt and connectivity Service to LKAAT rules

(formerly billing blocks)

  • Admin sees all service, which can be detected
  • Admin can create edit, rules by this schema: (1) LKAAT positions and (2) materials are created out of a detected service
Materials TBD, handed out, consumed? They are currently products and will be billed as WAR as they come from different catalogues.
Billing preparation screen Services are detected and show the matierals and LKAAT positions detected from that (formerly billing blocks)
  • LKAAT positions were detected by the LKAAT rules
  • Materials are shown, after
  • Materials can be added / removed manually
  • LKAAT positions can be added / removed manually

Please note, that all encounters till 31.12.2025 must use the old Billing-Flow, Encounters from 01.01.2026 must use the new billing flow

TBD
Billing creation flow
  • Processing according to TARDOC schema SOURCECODE exists in java, adapted to C#
  • TARDOC will regularly distribute new jsons: grouper.json, mapper,json for rules. Jsons can be uploaded somewhere and can be marked with a validity period.
  • Use CaseMaster, Grouper and Mapper to get bill.xml
  • Display the bill in the UI
Grouper and mapper jsons do not exists. Ther are functions in TARDOC matcher.

Understanding of the logic is off.

Bill upload
  • No signing required any more, because doctor signed the examinations
  • Bill can be clears the bill for upload
  • Bill is uploaded and visible in Medidata Transport syystem
First two points have to be reviewed, on sign the date is set.

This would obsolete draft bills then.

  • Setup a Realm
  • Deploy Kordeus
  • Build Connection to Transmit files to MediData
  • We have a fresh fully running Kordeus integration environment which is not identical with the current envirnment, which we need to other tasks testing. This needs to be independent and only for TARDOC testing
  • In the Test environment of Medidata (Seiler IPR AG - Webservice 1) we can upload files from Kordeus Integration
Who is responsible for setting up this?
Mid November Deployment on integration enviroment Testing and refinement by Marco
12.12. Doctors training on integration environment

See also