PheDRS

= Phenotype Detection Registry System (PheDRS) User Documentation =

Overview
The Phenotype Detection Registry System (PheDRS) is a tool at UAB used to assist researchers and clinicians identify populations of interest at UAB matching clinical criteria from both structured data (billing codes, medications, labs) and unstructured documents using Natural Language Processing. The user documentation described here is intended for managers and users of the PheDRS system.

Additional documentation for PheDRS is found in the following locations:

1. Project specific information is found in the appropriate git repo wikis and markdown text

2. UAB specific developer documentation is found in the UAB_BioMedInformatics\PHEDRS Box directory

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

Roles
PheDRS supports the following user roles:

Manager
The manager of a registry. Full read and write access to the registry. Can add new users as registrars or managers to the registry.

Registrar
A user with read and write access to the registry.

Administrator
System administrator responsible for maintaining the entire PheDRS system including all registries.

Viewer
Read only access to the registry.

Inactive
Former registrars no longer active.

De-ID Viewer
Viewer allowed to view de-identified data (18 HIPAA Safe Harbor items removed) data.

Registry Configuration
The registry is configured by the registry manager, often in conjunction with the system administrator.

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.

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"

Evidence Code Ontology
The evidence code ontology is used to describe how a patient's status in the registry (ACCEPTED, REJECTED, CANDIDATE OR PROVISIONAL) has been decided.

Code Discovered Patients

 * 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

 * Registry cvtermprop value must have criteria for "Encounter Intervention" or "Encounter Detection" and non-null SQL clause in the value field

NLP Discovered Patients
TODO - make separate CV for this
 * 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 ("detection NLP criteria" or "inclusion NLP criteria" or "intervention NLP criteria")