PheDRS - Revision history

Ozborn@uab.edu: /* NLP Discovered Patients */

2019-01-30T17:38:14Z

NLP Discovered Patients

← Older revision		Revision as of 17:38, 30 January 2019
Line 252:		Line 252:
	* Registry cvtermprop value must have criteria for "Encounter Intervention" or "Encounter Detection" and non-null SQL clause in the value field		* Registry cvtermprop value must have criteria for "Encounter Intervention" or "Encounter Detection" and non-null SQL clause in the value field
	==== NLP Discovered Patients ====		==== NLP Discovered Patients ====
	* Registry cvtermprop must have property in cvtermprop starting with "NLP" AND ending with ("Detection" or "Intervention")		* Registry cvtermprop must have property in cvtermprop starting with "NLP" AND ending with ("Detection" or "Intervention" or "Inclusion")
	* Registry cvtermprop must have a type_id with appropriate ontology AND a value that ends with ("NLP criteria" or "inclusion NLP criteria" or "intervention NLP criteria")		* Registry cvtermprop must have a type_id with appropriate ontology AND a value that ends with ("detection NLP criteria" or "inclusion NLP criteria" or "intervention NLP criteria")
	TODO - make separate CV for this		TODO - make separate CV for this

Ozborn@uab.edu: /* Evidence Code Ontology */ Updating NLP

2019-01-30T17:31:06Z

Evidence Code Ontology: Updating NLP

← Older revision		Revision as of 17:31, 30 January 2019
Line 247:		Line 247:
	=== Registry Cvtermprop Data Loading Values for Evidence Updating ===		=== Registry Cvtermprop Data Loading Values for Evidence Updating ===
	==== Code Discovered Patients ====		==== Code Discovered Patients ====
	* Registry cvtermprop value ~~must end~~ with "diagnosis criteria" or "inclusion criteria"		* Registry cvtermprop must have property in cvtermprop starting with "Code" and ending with "Detection"
			* Registry cvtermprop must have a type_id with appropriate ontology and a value that ends with "diagnosis criteria" or "inclusion criteria"
	==== Encounter Discovered Patients ====		==== Encounter Discovered Patients ====
	* Registry cvtermprop value must have criteria for "Encounter Intervention" or "Encounter Detection" and non-null SQL clause in the value field		* Registry cvtermprop value must have criteria for "Encounter Intervention" or "Encounter Detection" and non-null SQL clause in the value field
	==== NLP Discovered Patients ====		==== NLP Discovered Patients ====
	* Registry cvtermprop value ~~must end~~ with "NLP criteria" or "inclusion NLP criteria"		* Registry cvtermprop must have property in cvtermprop starting with "NLP" AND ending with ("Detection" or "Intervention")
			* Registry cvtermprop must have a type_id with appropriate ontology AND a value that ends with ("NLP criteria" or "inclusion NLP criteria" or "intervention NLP criteria")
	TODO - make separate CV for this		TODO - make separate CV for this

Ozborn@uab.edu: /* Evidence Code Ontology */

2019-01-30T17:19:45Z

Evidence Code Ontology

← Older revision		Revision as of 17:19, 30 January 2019
Line 244:		Line 244:
	\|-		\|-
	\|}		\|}

			=== Registry Cvtermprop Data Loading Values for Evidence Updating ===
			==== Code Discovered Patients ====
			* Registry cvtermprop value must end with "diagnosis criteria" or "inclusion criteria"
			==== Encounter Discovered Patients ====
			* Registry cvtermprop value must have criteria for "Encounter Intervention" or "Encounter Detection" and non-null SQL clause in the value field
			==== NLP Discovered Patients ====
			* Registry cvtermprop value must end with "NLP criteria" or "inclusion NLP criteria"
			TODO - make separate CV for this

	== Back End Workflow / Architecture ==		== Back End Workflow / Architecture ==

Ozborn@uab.edu: /* Developer Guide to PheDRS Data Loading Criteria */ Updating vocabulary meaning.

2019-01-30T16:59:05Z

Developer Guide to PheDRS Data Loading Criteria: Updating vocabulary meaning.

← Older revision		Revision as of 16:59, 30 January 2019
Line 131:		Line 131:

	=== Developer Guide to PheDRS Data Loading Criteria ===		=== Developer Guide to PheDRS Data Loading Criteria ===

			==== Data Loading Vocabulary ====
			* '''Code''' - Structured data in the ''REGISTRY_PATIENT_CODES'' table including ICD-10-CM codes, DRG codes, MULTUM medication codes, etc...
			* '''NLP''' - UMLS CUIs stored (currently) in the medics schema
			* '''Encounter''' - Encounter data stored in ''REGISTRY_ENCOUNTER''
			* '''Detection''' - Indicates that detected patient will be added as candidates to a registry
			* '''Intervention''' - Like detection, but the Intervention property will be set on the patient regardless of status
			* '''Collection''' - The data type will be copied to the ''REGISTRY_PATIENT_CODES'' table or ''REGISTRY_ENCOUNTER'' from the appropriate ETL table

			==== Data Loading Process ====
	This table details how the PheDRS Data Loading Criteria ontology is used to by backend clients (controlled by loadAll.bsh) to set patient status and review status. Like other registry configuration criteria, the configuration information is stored in the cvterm and cvtermprop for that registry.		This table details how the PheDRS Data Loading Criteria ontology is used to by backend clients (controlled by loadAll.bsh) to set patient status and review status. Like other registry configuration criteria, the configuration information is stored in the cvterm and cvtermprop for that registry.

Line 203:		Line 213:
	\| Document Loading (deprecated) \|\| Existence of documents \|\| Provisional\|Accepted \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| Load NLP_DOCS from source systems for registry patients \|\| Should be a default analysis type that is used for CVTERMPROP		\| Document Loading (deprecated) \|\| Existence of documents \|\| Provisional\|Accepted \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| Load NLP_DOCS from source systems for registry patients \|\| Should be a default analysis type that is used for CVTERMPROP
	\|}		\|}


	== Evidence Code Ontology ==		== Evidence Code Ontology ==

Ozborn@uab.edu: /* Phenotype Detection Registry System (PheDRS) User Documentation */ Evidence Codes

2019-01-24T20:39:55Z

Phenotype Detection Registry System (PheDRS) User Documentation: Evidence Codes

@@ Line 202: / Line 202: @@
 |-
 | Document Loading (deprecated) || Existence of documents || Provisional|Accepted || ANY || ANY || NO CHANGE || NO CHANGE || NO CHANGE || Load NLP_DOCS from source systems for registry patients || Should be a default analysis type that is used for CVTERMPROP
 |}

Ozborn@uab.edu: /* Installation / Setup */ TODO

2019-01-24T20:28:59Z

Installation / Setup: TODO

← Older revision		Revision as of 20:28, 24 January 2019
Line 12:		Line 12:

	== Installation / Setup ==		== Installation / Setup ==
			TODO

	Currently this is very site specific and depends on various backend systems, EHR vendors, etc... UAB specific site setup can be found in the UAB_BioMedInformatics\PHEDRS Box directory		Currently this is very site specific and depends on various backend systems, EHR vendors, etc... UAB specific site setup can be found in the UAB_BioMedInformatics\PHEDRS Box directory


	== Roles ==		== Roles ==

Ozborn@uab.edu: /* Developer Guide to PheDRS Data Loading Criteria */

2019-01-18T20:19:00Z

Developer Guide to PheDRS Data Loading Criteria

← Older revision		Revision as of 20:19, 18 January 2019
Line 172:		Line 172:
	\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|		\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|
	\|-		\|-
	\| Eligibility \|\| Custom \|\| ANY \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| Machine learning of patient eligibility \|\| Custom registry specific implementation that should result in a publication… :)		\| Eligibility \|\| Custom \|\| ANY \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| Machine learning of patient eligibility MACHINE_ACCEPTANCE_SCORE in REGISTRY_PATIENT is set to a non-zero value \|\| Custom registry specific implementation that should result in a publication… :)
	\|-
	~~\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| MACHINE_ACCEPTANCE_SCORE in REGISTRY_PATIENT \|\|~~
	\|-
	~~\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| is set to a non-zero value \|\|~~
	\|-		\|-
	\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|		\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|
Line 192:		Line 188:
	\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|		\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|
	\|-		\|-
	\| Encounter Intervention \|\| Encounter \|\| ANY \|\| ANY \|\| Requires Intervention \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| NO CHANGE \|\| Encounters matching criteria specified in CVTERM_PROP \|\| CVTERMPROP has cvterm_id (registry_id) and type_id (sourcesystem_cd) and value in SQL format		\| Encounter Intervention \|\| Encounter \|\| ANY \|\| ANY \|\| Requires Intervention \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| NO CHANGE \|\| Encounters matching criteria specified in CVTERM_PROP (which contains WHERE clause SQL) are loaded into REGISTRY_ENCOUNTERS \|\| CVTERMPROP has cvterm_id (registry_id) and type_id (sourcesystem_cd) and value in SQL format
	\|-		\|-
	\| \|\|\|\| ANY \|\| ANY \|\| Intervention Complete < Encounter Date \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| Requires Intervention \|\| ~~(which contains WHERE clause SQL) are loaded into~~ \|\|		\| \|\|\|\| ANY \|\| ANY \|\| Intervention Complete < Encounter Date \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| Requires Intervention \|\| \|\|
	\|-		\|-
	\| \|\| \|\| ANY \|\| ANY \|\| Any other current valid cvterms \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| Requires Intervention \|\| ~~REGISTRY_ENCOUNTERS~~ \|\|		\| \|\| \|\| ANY \|\| ANY \|\| Any other current valid cvterms \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| Requires Intervention \|\| \|\|
	\|-		\|-
	\| \|\| \|\| ANY \|\| ANY \|\| Intervention Complete > Encounter Date \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| NO CHANGE \|\| Flag patients for intervention \|\|		\| \|\| \|\| ANY \|\| ANY \|\| Intervention Complete > Encounter Date \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| NO CHANGE \|\| Flag patients for intervention \|\|

Ozborn@uab.edu: /* Developer Guide to PheDRS Data Loading Criteria */

2019-01-18T19:54:48Z

Developer Guide to PheDRS Data Loading Criteria

← Older revision		Revision as of 19:54, 18 January 2019
Line 138:		Line 138:

	{\| class="wikitable"		{\| class="wikitable"
	! Criteria Name !! Event Description !! Input Patient Registry Status !! Input Patient Review Status !! Input ~~REGISTRY_PATIENT~~ _CVTERM !! Output Patient Registry Status Change !! Output Patient Review Status !! Output ~~REGISTRY_PATIENT~~ _CVTERM !! Action Description !! Implementation Notes		! Criteria Name !! Event Description !! Input Patient Registry Status !! Input Patient Review Status !! Input REGISTRY _PATIENT _CVTERM !! Output Patient Registry Status Change !! Output Patient Review Status !! Output REGISTRY _PATIENT _CVTERM !! Action Description !! Implementation Notes
	\|-		\|-
	\| Diagnosis (Code_Detection) \|\| PATIENT_CODE entry hat matches diagnosis criteria in CVTERMPROP \|\| NULL \|\| NULL \|\| NULL \|\| CANDIDATE \|\| NEVER REVIEWED \|\| ANY \|\| Add candidate \|\| CVTERMs corresponding to codes have a CVTERMPROP set on them of type registry_name (from cv_id 11) with a value containing text "diagnosis criteria"		\| Diagnosis (Code_Detection) \|\| PATIENT_CODE entry hat matches diagnosis criteria in CVTERMPROP \|\| NULL \|\| NULL \|\| NULL \|\| CANDIDATE \|\| NEVER REVIEWED \|\| ANY \|\| Add candidate \|\| CVTERMs corresponding to codes have a CVTERMPROP set on them of type registry_name (from cv_id 11) with a value containing text "diagnosis criteria"
Line 204:		Line 204:
	\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|		\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|
	\|-		\|-
	\| Document Loading \|\| Existence of documents \|\| Provisional\|Accepted \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| Load NLP_DOCS from source systems for registry patients \|\| Should be a default analysis type that is used for CVTERMPROP		\| Document Loading (deprecated) \|\| Existence of documents \|\| Provisional\|Accepted \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| Load NLP_DOCS from source systems for registry patients \|\| Should be a default analysis type that is used for CVTERMPROP
	\|}		\|}

Ozborn@uab.edu: /* Developer Guide for Registry Configuration Properties */

2019-01-18T19:51:27Z

Developer Guide for Registry Configuration Properties

← Older revision		Revision as of 19:51, 18 January 2019
Line 129:		Line 129:
	\|}		\|}

	=== Developer Guide ~~for Registry Configuration Properties~~ ===		=== Developer Guide to PheDRS Data Loading Criteria ===
	This table details the ~~relationship between the registry PHEDRS back end processing script~~ and registry ~~specific~~ information in the ~~PHEDRS schema (encoded mostly in~~ cvterm and cvtermprop ~~tables)~~		This table details how the PheDRS Data Loading Criteria ontology is used to by backend clients (controlled by loadAll.bsh) to set patient status and review status. Like other registry configuration criteria, the configuration information is stored in the cvterm and cvtermprop for that registry.
	~~The goal is to have the back-end script reading the database to get registry specific parameters to detect patients and flag events~~ that ~~require~~ registry ~~review~~.
	These scripts detect patients for the registry (updating status_id) and flag patients for review (updating review_status_id) when registry specific events occur based on registry configuration.		These scripts detect patients for the registry (updating status_id) and flag patients for review (updating review_status_id) when registry specific events occur based on registry configuration.

	The server side process will never set the patient registry status to 'Under Review" or "Reviewed"		The server side process will never set the patient registry status to 'Under Review" or "Reviewed"

Ozborn@uab.edu: /* Developer Guide for Registry Configuration Properties */

2019-01-18T19:44:47Z

Developer Guide for Registry Configuration Properties

← Older revision		Revision as of 19:44, 18 January 2019
Line 130:		Line 130:

	=== Developer Guide for Registry Configuration Properties ===		=== Developer Guide for Registry Configuration Properties ===
			This table details the relationship between the registry PHEDRS back end processing script and registry specific information in the PHEDRS schema (encoded mostly in cvterm and cvtermprop tables)
	~~{\| class="wikitable"~~		The goal is to have the back-end script reading the database to get registry specific parameters to detect patients and flag events that require registry review.
	~~\|+ Developer Guide for Registry Configuration Properties~~		These scripts detect patients for the registry (updating status_id) and flag patients for review (updating review_status_id) when registry specific events occur based on registry configuration.
	\|-		The server side process will never set the patient registry status to 'Under Review" or "Reviewed"
	~~! CRITERIA NAME~~
	~~! EVENT DESCRIPTION~~
	~~! Input Patient Registry Status~~
	~~! Input Patient Review Status~~
	~~! Input Required Registry Patient Cvterm/s~~
	~~! Outputput Patient Registry Status~~
	~~! Output Patient Review Status~~
	~~! Output Change~~ to ~~Registry Patient Cvterm/s~~
	~~! Action Description~~
	~~! Implementation Notes~~
	\|-
	~~\|Diagnosis~~ (~~Code_Detection~~)
	~~\|PATIENT_CODE entry that matches diagnosis criteria in CVTERMPROP~~
	~~\|NULL~~
	~~\|NULL~~
	~~\|NULL~~
	~~\|CANDIDATE~~
	~~\|NEVER REVIEWED~~
	~~\|ANY~~
	~~\|Add candidate~~
	~~\|CVTERMs corresponding~~ to ~~codes have a CVTERMPROP set on them of type registry_name (from cv_id 11) with a value containing text~~ "~~diagnosis criteria~~"
	\|}


	{\| class="wikitable"		{\| class="wikitable"
	! Criteria Name !! Event Description !! Input Patient Registry Status !! Input Patient Review Status !! Input REGISTRY_PATIENT _CVTERM !! Output Patient Registry Status !! Output Patient Review Status !! Output REGISTRY_PATIENT _CVTERM !! Action Description !! Implementation Notes		! Criteria Name !! Event Description !! Input Patient Registry Status !! Input Patient Review Status !! Input REGISTRY_PATIENT _CVTERM !! Output Patient Registry Status Change !! Output Patient Review Status !! Output REGISTRY_PATIENT _CVTERM !! Action Description !! Implementation Notes
	\|-		\|-
	\| Diagnosis (Code_Detection) \|\| PATIENT_CODE entry hat matches diagnosis criteria in CVTERMPROP \|\| NULL \|\| NULL \|\| NULL \|\| CANDIDATE \|\| NEVER REVIEWED \|\| ANY \|\| Add candidate t \|\| CVTERMs corresponding to codes have a CVTERMPROP set on them of type registry_name (from cv_id 11) with a value containing text "diagnosis criteria"		\| Diagnosis (Code_Detection) \|\| PATIENT_CODE entry hat matches diagnosis criteria in CVTERMPROP \|\| NULL \|\| NULL \|\| NULL \|\| CANDIDATE \|\| NEVER REVIEWED \|\| ANY \|\| Add candidate \|\| CVTERMs corresponding to codes have a CVTERMPROP set on them of type registry_name (from cv_id 11) with a value containing text "diagnosis criteria"
	\|-		\|-
	\| \|\| \|\| Rejected\|Provisional \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NEEDS REVIEW \|\| ANY \|\| Flag rejected and provisional candidates for review \|\| Plan is to swap CVTERMs such that CVTERM_ID is the registry and the TYPE_ID is the code		\| \|\| \|\| Rejected\|Provisional \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NEEDS REVIEW \|\| ANY \|\| Flag rejected and provisional candidates for review \|\| Plan is to swap CVTERMs such that CVTERM_ID is the registry and the TYPE_ID is the code
Line 192:		Line 170:
	\|-		\|-
	\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|		\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|
	\|-
	~~\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|~~
	\|-		\|-
	\| Eligibility \|\| Custom \|\| ANY \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| Machine learning of patient eligibility \|\| Custom registry specific implementation that should result in a publication… :)		\| Eligibility \|\| Custom \|\| ANY \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| Machine learning of patient eligibility \|\| Custom registry specific implementation that should result in a publication… :)
Line 209:		Line 185:
	\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|		\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|
	\|-		\|-
	\| Encounter Collection \|\| ~~COPD,CRCP(?) \|\|~~ None (daily) \|\| Rejected\|Candidate \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| Collect specified encounter data for people in the registry \|\| CVTERMPROP has cvterm_id (registry_id) and type_id (sourcesystem_cd) and value in the format below		\| Encounter Collection \|\| None (daily) \|\| Rejected\|Candidate \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| Collect specified encounter data for people in the registry \|\| CVTERMPROP has cvterm_id (registry_id) and type_id (sourcesystem_cd) and value in the format below
	\|-		\|-
	~~\| \|\| \|~~\| \|\| Provisional\|Accepted \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| \|\| REGISTRY_ENCOUNTER COLUMN_NAME\|REGEX\|\|REGISTRY_ENCOUNTER_COLUMN_NAME\|REGEX….		\| \|\| Provisional\|Accepted \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| \|\| REGISTRY_ENCOUNTER COLUMN_NAME\|REGEX\|\|REGISTRY_ENCOUNTER_COLUMN_NAME\|REGEX….
	\|-		\|-
	\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|		\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|
	\|-		\|-
	\| Encounter Intervention ~~\|\| COPD~~ \|\| Encounter \|\| ANY \|\| ANY \|\| Requires Intervention \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| NO CHANGE \|\| Encounters matching criteria specified in CVTERM_PROP \|\| CVTERMPROP has cvterm_id (registry_id) and type_id (sourcesystem_cd) and value in SQL format		\| Encounter Intervention \|\| Encounter \|\| ANY \|\| ANY \|\| Requires Intervention \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| NO CHANGE \|\| Encounters matching criteria specified in CVTERM_PROP \|\| CVTERMPROP has cvterm_id (registry_id) and type_id (sourcesystem_cd) and value in SQL format
	\|-		\|-
	\| \|\| \|\| \|\| ANY \|\| ANY \|\| Intervention Complete < Encounter Date \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| Requires Intervention \|\| (which contains WHERE clause SQL) are loaded into \|\|		\| \|\|\|\| ANY \|\| ANY \|\| Intervention Complete < Encounter Date \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| Requires Intervention \|\| (which contains WHERE clause SQL) are loaded into \|\|
	\|-		\|-
	\| \|\| \|\| \|\| ANY \|\| ANY \|\| Any other current valid cvterms \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| Requires Intervention \|\| REGISTRY_ENCOUNTERS \|\|		\| \|\| \|\| ANY \|\| ANY \|\| Any other current valid cvterms \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| Requires Intervention \|\| REGISTRY_ENCOUNTERS \|\|
	\|-		\|-
	\| \|\| \|\| \|\| ANY \|\| ANY \|\| Intervention Complete > Encounter Date \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| NO CHANGE \|\| Flag patients for intervention \|\|		\| \|\| \|\| ANY \|\| ANY \|\| Intervention Complete > Encounter Date \|\| NO CHANGE (CANDIDATE IF NULL) \|\| NO CHANGE \|\| NO CHANGE \|\| Flag patients for intervention \|\|
	\|-		\|-
	\| Encounter Detection \|\| None \|\| Encounter \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|		\| Encounter Detection \|\| None \|\| Encounter \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|
	\|-		\|-
	~~\| \|~~\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|		\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\|
	\|-		\|-
	\| Document Loading \|\| ~~COPD \|\| Exisitence~~ of documents \|\| Provisional\|Accepted \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| Load NLP_DOCS from source systems for registry patients \|\| Should be a default analysis type that is used for CVTERMPROP		\| Document Loading \|\| Existence of documents \|\| Provisional\|Accepted \|\| ANY \|\| ANY \|\| NO CHANGE \|\| NO CHANGE \|\| NO CHANGE \|\| Load NLP_DOCS from source systems for registry patients \|\| Should be a default analysis type that is used for CVTERMPROP
	\|}		\|}