TARDOC Bill creation / transmission

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 encounter 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	Doctors can not edit anything in the form without having started the examination timer TBD depending on the encounter How to handle Alex?
		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 https://medcode.ch/de/de/static_pages/api_documentation Free text diagnoses? Are diagnoses related to services?
		ICD-Rule-Editor (not 1. Priority)	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 (not 1. Priority)	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	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. Keep same UI for medical services
		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	Logic stays the same for products and other catalogues than LKAAT/TARDOC
		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. Update: Discussed with Stefan.
		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. Bill has to be signed
		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? See with SSeiler
Mid November	Deployment on integration enviroment		Testing and refinement by Marco
12.12.	Doctors training on integration environment

1. Data Model and API Integration

The core of the migration is a robust data model that can handle both old and new diagnoses. It must adapt the existing diagnosis table to correctly capture the ICD-10-GM codes and their associated statuses.

Extended Diagnosis Table

• id: Unique ID for each diagnosis entry.
• patient_id: Link to the patient.
• icd10_code: String. The central field for the ICD-10-GM code (e.g., "H25.9"). This field is mandatory for new entries.
• icd10_version: String. The version of the ICD-10-GM catalog (e.g., "2026").
• diagnosis_certainty: Enum. The crucial status of diagnosis certainty. Values:
  • G_CONFIRMED
  • V_SUSPECTED
  • A_RULED_OUT
  • Z_HISTORY_OF
• date_of_diagnosis: Timestamp. The exact date the diagnosis was made.
• original_text: String. The original free-text of the diagnosis. To be preserved for old entries.
• diagnosis_type: Enum. Indicates whether the entry is an ICD-10 code (ICD10_GM) or free-text (FREE_TEXT).

2. User Interface (UI) and Workflow

The UI must be designed to guide physicians through the new coding process efficiently and intuitively.

Diagnosis Entry Screen

• Search and Selection (left): A central search field with autocomplete, powered by the medcode.ch API. Doctors can search by code or keyword. Free-text entries without an assigned code are not possible.
• Quick Selection: Below the search field are two lists for fast access:
  • Favorites: A personalized list of the physician's most frequently used diagnoses. These can be selected with a single click.
  • Recently Used: A dynamic list of the most recent diagnoses, allowing for quick reuse.
• Mandatory Fields: After selecting an ICD code, the physician must select the Diagnosis Certainty (G, V, A, Z) from a dropdown menu. The date_of_diagnosis field is pre-filled with the consultation date but can be adjusted.
• Active Diagnoses (right): A list of selected diagnoses showing the code, clear text, and chosen status. The order can be adjusted via drag-and-drop.

Workflow Example

1. A doctor types a term into the search field.
2. They select an ICD code from the autocomplete list.
3. They choose the status (e.g., "G_CONFIRMED") and confirm the date.
4. The entry is added to the patient's diagnosis list.

3. Reporting and Chronology

The reporting module must prepare data to correctly populate the Word document placeholders, ensuring all information and chronology are preserved.

Logic for Placeholder Population

The module must query the patient's diagnoses, sort them chronologically by date_of_diagnosis, and then generate the appropriate text for each entry.

• New Diagnoses (ICD10_GM):
  • Output: [Code] – [Clear Text] ([Status])
  • Example: H25.9 – Age-related cataract, unspecified (Confirmed Diagnosis)
• Old Diagnoses (FREE_TEXT):
  • Output: [Original Text] [Free text, pre-2026]
  • Example: Cataract, right eye [Free text, pre-2026]

Billing Fundamentals

Generally there are two patient billing flows:

• Direct billing flow - There exists no framework on which the bill is restricted. The bill is directly written to the patient which is paying the bill.
• Health insurance billing flow - There exists frameworks defined by health insurance providers to which the doctor has to adhere to get the money (e.g. TARMED, TARDOC, GOÄ, EGO, ... )

Performed service status

• Uncharged - no billable positions exist, which reference to this performed service
• Billing preparation - billable positions exist, which reference to this performed service, but not all bills these are part of are issued
• Billed - billable positions exist, which reference to this performed service, All billable positions are referenced to an issued bill.

Bill issuance status

• Draft with Errors - The bill draft is created, but could not be validated or is incomplete
• Draft OK - The bill draft has been created and validated and is ready for being issued.
• Bill issued - The bill has been issued and has received a bill number, and is also transported into book-keeping (bookings have been made)
• Cancelled - The bill was issued and then cancelled. Bookings have been made to revert the bookings of the issuance

While the bill changes its status, the performed services status is changing as well. On issuance and cancellation, there have to be book-keeping bookings each with transaction numbers for bookkeeping.

Bill delivery status

Each practise needs to track information on how the bill is transmitted to the patient. So we need to track these status info:

• IsETransmitted
• IsPaperTransmission
• DateOfSendout
• HasResponse_Confirmed
• HasResponse_Rejected
• DateOfResponse

See also

• Kordeus Core