Dev:Diagnoses - Revision history

Stefanseiler: /* Diagnose catalogs */

2026-05-06T23:22:24Z

Diagnose catalogs

← Older revision		Revision as of 23:22, 6 May 2026
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 20:		Line 19:
	====== Describe the reason for billing ======		====== Describe the reason for billing ======
	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.		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.

			== 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.
	[[Category:Fundamental Healthcare Data Entities]]		[[Category:Fundamental Healthcare Data Entities]]

Stefanseiler: /* Describe the reason for billing */

2026-05-06T23:07:40Z

Describe the reason for billing

@@ Line 19: / Line 19: @@
 ====== 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.
 [[Category:Fundamental Healthcare Data Entities]]

Stefanseiler at 23:05, 6 May 2026

2026-05-06T23:05:26Z

← Older revision		Revision as of 23:05, 6 May 2026
Line 3:		Line 3:

	* '''Hierarchically Grouped''', e.g. by organs, specializations, ...		* '''Hierarchically Grouped''', e.g. by organs, specializations, ...
	* '''Described''' (e.g. ~~by code, name, ...~~ )		* '''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)		* '''Localized''', attributed to organ-structures as potential localizations (e.g. Left/Right eye)

Line 18:		Line 19:

	====== Describe the reason for billing ======		====== 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.		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.

	{{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.}}		{{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.}}

Stefanseiler at 20:07, 6 May 2026

2026-05-06T20:07:10Z

← Older revision		Revision as of 20:07, 6 May 2026
Line 34:		Line 34:
	* 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.		* 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.		* 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]]

Stefanseiler: /* Describe a time-based state of a patient */

2026-03-30T14:31:41Z

Describe a time-based state of a patient

← Older revision		Revision as of 14:31, 30 March 2026
Line 12:		Line 12:
	* <code>ruled out</code>		* <code>ruled out</code>
	* <code>active</code> (default state)		* <code>active</code> (default state)
	* <code>inactive</code> - this is no longer active diagnose, where you ~~see a remaint~~ of the formerly active diagnose		* <code>inactive</code> - this is no longer active diagnose, where you do not longer have remaints of the formerly active diagnose
	* <code>condition after</code> - this is no longer active diagnose, where you ~~see~~ a remaint of the formerly active diagnose		* <code>condition after</code> - this is no longer active diagnose, where you have a remaint of the formerly active diagnose

	{{Yellow-Tag\|YellowText=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.}}		{{Yellow-Tag\|YellowText=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.}}

Stefanseiler: /* Describe a time-based state of a patient */

2026-03-30T14:31:05Z

Describe a time-based state of a patient

← Older revision		Revision as of 14:31, 30 March 2026
Line 12:		Line 12:
	* <code>ruled out</code>		* <code>ruled out</code>
	* <code>active</code> (default state)		* <code>active</code> (default state)
	* <code>condition after</code>		* <code>inactive</code> - this is no longer active diagnose, where you see a remaint of the formerly active diagnose
			* <code>condition after</code> - this is no longer active diagnose, where you see a remaint of the formerly active diagnose

	{{Yellow-Tag\|YellowText=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.}}		{{Yellow-Tag\|YellowText=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.}}

Stefanseiler: /* Describe the reason for billing */

2026-03-30T13:59:19Z

Describe the reason for billing

← Older revision		Revision as of 13:59, 30 March 2026
Line 25:		Line 25:
	* The encounter type administration bears ruletypes for		* 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		** '''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''' - 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.		** '''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.		* 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		* 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

Stefanseiler at 13:54, 30 March 2026

2026-03-30T13:54:38Z

← Older revision		Revision as of 13:54, 30 March 2026
Line 17:		Line 17:

	====== Describe the reason for billing ======		====== Describe the reason for billing ======
	~~When it comes to billing medical services, each service~~ '''~~must~~''' be attributed to ~~one~~ of the diagnoses ever ~~diagnosed~~ with the ~~patient~~. ~~This~~ is ~~because health insurances~~ '''~~do not~~''' ~~pay~~ treatment without ~~indication~~.		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.

			{{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.}}

			How we implement this:

			* 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''' - 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.

Stefanseiler at 13:25, 30 March 2026

2026-03-30T13:25:02Z

← Older revision		Revision as of 13:25, 30 March 2026
Line 14:		Line 14:
	* <code>condition after</code>		* <code>condition after</code>

	{{Yellow-Tag\|YellowText=Please note that diagnose states ~~will~~ change over time! ~~Also localizations can change.~~ So a once diagnosed diagnose with a patient will stay over all time, just the status and localizations may change over time.}}		{{Yellow-Tag\|YellowText=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 ======		====== Describe the reason for billing ======
	When it comes to billing medical services, each service '''must''' be attributed to one of the diagnoses ever diagnosed with the patient. This is because health insurances '''do not''' pay treatment without indication.		When it comes to billing medical services, each service '''must''' be attributed to one of the diagnoses ever diagnosed with the patient. This is because health insurances '''do not''' pay treatment without indication.

Stefanseiler at 13:24, 30 March 2026

2026-03-30T13:24:06Z

← Older revision		Revision as of 13:24, 30 March 2026
Line 14:		Line 14:
	* <code>condition after</code>		* <code>condition after</code>

	{{Yellow-Tag\|YellowText=Please note that diagnose states will change over time! So a once diagnosed diagnose with a patient will stay over all time, just the status ~~changes~~ over time.}}		{{Yellow-Tag\|YellowText=Please note that diagnose states will change over time! Also localizations can change. 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 ======		====== Describe the reason for billing ======
	When it comes to billing medical services, each service '''must''' be attributed to one of the diagnoses ever diagnosed with the patient. This is because health insurances '''do not''' pay treatment without indication.		When it comes to billing medical services, each service '''must''' be attributed to one of the diagnoses ever diagnosed with the patient. This is because health insurances '''do not''' pay treatment without indication.