Dev:Diagnoses: Difference between revisions

From Kordeus Wiki
Jump to navigation Jump to search
← Older edit
VisualWikitext
Stefanseiler (talk | contribs)
Bureaucrats, dev-team, developer, Interface administrators, iroc-team, Suppressors, Administrators, yousee-team
1,490 edits
No edit summary
Stefanseiler (talk | contribs)
Bureaucrats, dev-team, developer, Interface administrators, iroc-team, Suppressors, Administrators, yousee-team
1,490 edits
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
====== Diagnose catalogs ======
Diagnoses are stored in hierarchical '''diagnose catalogs''', e.g. ICD-10. Where diagnoses are:
Diagnoses are stored in hierarchical '''diagnose catalogs''', e.g. ICD-10. Where diagnoses are:


Line 19: Line 18:


====== Describe the reason for billing ======
====== Describe the reason for billing ======
As health insurances '''do not''' pay treatment without [[Medical indication|indication]], each billing position must be attributed to a '''diagnose''' and a '''localization''' of the delivered treatment.
As health insurances '''do not''' pay treatment without [[Medical indication|indication]], each [[Medical Billing Flows|billing position]] must be attributed an indication (in most cases a '''diagnose''') for each of the billable treatments.


{{Red-Tag|Text=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.}}
== Diagnose entry ==
Each practise defines one or multiple permitted diagnose catalogs, e.g. "ICD-10" and "Tessiner Diagnosenkatalog". These catalogs may hold  multiple descriptions, where there is one primary and more secondard descriptions. All of them can be searched in a full-text search. If the doctor decides for one match, still the unique code is picked and the picked match (no matter if its the primary or a secondary text).


How we implement this:
Fulltext search must implement: features like Autocompleteion, Relevance search, NGram and Typo correction.
 
* The encounter type administration bears ruletypes for
** '''Diagnose addition rules''' - you can specify <code>diagnose</code> and <code>state</code> added by default if this encounter type is started
** '''Treatment reason rules (treatment indication)''' - you can specify the default <code>treatment reason diagnoses</code>  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 <u>current</u> state) will be made the default <code>treatment reason</code> for all services of this encounter.
* When the doctor is opening the encounter, we allow the definition of <code>treatment reason diagnose'''s'''</code>. 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 <code>treatment reason diagnoses</code> and billed services/products. Each assignment is one of these types
** <code>Allowed</code> - This position goes well
** <code>Questionable</code> - This position is questionable. This highlights the doctor that it might make sense to  change the associated diagnose on this billing position
** <code>Not allowed</code> - This position will certainly lead to rejection by health insurances
* When creating the bill, Per billing position, we try to find matching <code>treatment reason diagnoses</code> on the encounter and automatically assign them to the billing position (matching <code>treatment reason diagnoses</code> with higher ordersequence beat lower ones). Positions, to which no <code>treatment reason diagnose</code> 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.
[[Category:Fundamental Healthcare Data Entities]]
[[Category:Fundamental Healthcare Data Entities]]

Latest revision as of 23:22, 6 May 2026

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

  • Hierarchically Grouped, e.g. by organs, specializations, ...
  • Coded, each diagnose has a unique code
  • Described - might have multipe descriptions per language (e.g. "Fuchs" or "Herediäre Hornhautdystrophie" which are both synonmy)
  • 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 do not longer have remaints of the formerly active diagnose
  • condition after - this is no longer active diagnose, where you have 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 an indication (in most cases a diagnose) for each of the billable treatments.

Diagnose entry

Each practise defines one or multiple permitted diagnose catalogs, e.g. "ICD-10" and "Tessiner Diagnosenkatalog". These catalogs may hold multiple descriptions, where there is one primary and more secondard descriptions. All of them can be searched in a full-text search. If the doctor decides for one match, still the unique code is picked and the picked match (no matter if its the primary or a secondary text).

Fulltext search must implement: features like Autocompleteion, Relevance search, NGram and Typo correction.

Retrieved from "https://wiki.kordeus.com/index.php?title=Dev:Diagnoses&oldid=3355"