TARDOC Bill creation / transmission: Difference between revisions

From Kordeus Wiki
Jump to navigation Jump to search
Stefanseiler (talk | contribs)
No edit summary
Stefanseiler (talk | contribs)
No edit summary
Line 38: Line 38:
* 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
|-
|-
|LKAAT Rule Editor
|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  
* The admin can create rules, which encounter data drives which LKAAT position with Tiggerconditions (AND OR connected) and a resulting ICD-10 Diagnose  
Line 80: Line 81:
|
|
* 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
* nd make it searchable
|-
|-
|
|
|
|
|
|
|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
|-
|
|
|
|
|
|
|
|
* Behind the services, which are associated with the documentation we have to bind LKAAT positions
|Billing preparation screen
* These will be detected and put on the delivered services list
|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
|-
|-
|
|
Line 95: Line 107:
|
|
|
|
|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
|-
|-
|
|
| colspan="3" |
| colspan="3" |
|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
|-
|-
|
|

Revision as of 14:55, 15 September 2025

Date Milestone ToDo Definition of Done / Acceptance Criteria
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
Create ICD-10 catalog to incorporate in the system
  • We have a searchable catalog (fulltext search) in some service, which can be searched realtime
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
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
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)
Mid October Golive in IROC of ICD-10 qualification and time-tracking
Import LKAAT catalog into system
  • 30.09. is the official publish date of TARDOC LKAAT catalog json, we need to form a catalog
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
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
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
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
Integration environemt and connectivity
  • 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
30.09. LKAAT json is published Download and provide to Goran
Casemaster viewer


Kordeus.CORE