Dev:Diagnoses

Diagnose catalogs

Diagnoses are stored in hierarchical diagnose catalogs, e.g. ICD-10. Where diagnoses are:

• Hierarchically Grouped, e.g. by organs, specializations, ...
• Described (e.g. by code, name, ... )
• Localized, attributed to organ-structures as potential localizations (e.g. Left/Right eye)

Describe a time-based state of a patient

Diagnoses can be added to a patient by the doctor with a diagnose date. This can happen as part of a regular encounter or by adding historical data. Upon entering the diagnose, the doctor has to define a diagnose state and the localization of the diagnose. The potential localizations come from the diagnose catalogs, there exist these diagnose states.

• suspected
• ruled out
• active (default state)
• inactive - this is no longer active diagnose, where you see a remaint of the formerly active diagnose
• condition after - this is no longer active diagnose, where you see a remaint of the formerly active diagnose

Please note that diagnose states and diagnose localizations may be subject to change over time! So a once diagnosed diagnose with a patient will stay over all time, just the status and localizations may change over time.

Describe the reason for billing

As health insurances do not pay treatment without indication, each billing position must be attributed to a diagnose and a localization of the delivered treatment.

Issue: Doctors do not want to enter per position a diagnose and localization as this is unpayed word and considered overhead. They expect our software to find the correct diagnose and localization for the billing position in 99.99% automatically.

How we implement this:

• The encounter type administration bears ruletypes for
  • Diagnose addition rules - you can specify diagnose and state added by default if this encounter type is started
  • Treatment reason rules (treatment indication) - you can specify the default treatment reason diagnoses for an encounter started (e.g. H25.x or H26.x for encounter type "Postexamination Cataracta"). So if a patient ever hadthis diagnose, the diagnose (with current state) will be made the default treatment reason for all services of this encounter.
• When the doctor is opening the encounter, we allow the definition of treatment reason diagnoses. Typically this is one diagnose, but can be multiple with a definable order sequence. When opening an encounter, they are automatically calculated from defined diagnose rules defined at the encounter type.
• Per billing position, we store in the background hold an asssignment of treatment reason diagnoses and billed services/products. Each assignment is one of these types
  • Allowed - This position goes well
  • Questionable - This position is questionable. This highlights the doctor that it might make sense to change the associated diagnose on this billing position
  • Not allowed - This position will certainly lead to rejection by health insurances
• When creating the bill, Per billing position, we try to find matching treatment reason diagnoses on the encounter and automatically assign them to the billing position (matching treatment reason diagnoses with higher ordersequence beat lower ones). Positions, to which no treatment reason diagnose could be found need to be filled in by the billing doctor manually. Each doctoral entry will be persisted to the assignment-list without asking the doctor.
• If doctors made wrong assignments, we can delete them through an administration tool for this assignments. Also assignments can be limited to a timeframe (and marked outdated) by having an end date for this assignment.