PheDRS
https://docs.rc.uab.edu/
Please use the new documentation url https://docs.rc.uab.edu/ for all Research Computing documentation needs.
As a result of this move, we have deprecated use of this wiki for documentation. We are providing read-only access to the content to facilitate migration of bookmarks and to serve as an historical record. All content updates should be made at the new documentation site. The original wiki will not receive further updates.
Thank you,
The Research Computing Team
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
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.
Registry Property Descriptions and Examples
| CV NAME | CV ID | Example of cvterm name for TYPE_ID | Meaning and Use of VALUE field for this type | Example of Value Field |
|---|---|---|---|---|
| UAB ICD-10-CM Codes | 9 | Panlobular emphysema | If patient has this billing code, assign as candidate to registry | UAB COPD Registry ICD-10-CM diagnosis criteria |
| UAB MS DRG Codes | 12 | COPD w CC | If patient has this DRG code, then add anchor cvterm property to this code | DRG Codes COPD Anchor Encounter criteria |
| COPD w MCC | If patient has this DRG code, then add patient to the registry as "accepted" | UAB COPD Registry DRG Codes inclusion criteria | ||
| PHEDRS Data Loading Criteria | 23 | Default NLP Pipeline Collection | This is the ID# of the default pipeline for displaying documents in this registry. Unenforced Foreign Key to db_id=14 | 2 |
| Encounter Collection | Encounters matching the appended SQL criteria are added to the registry | AND (SRC_ADMIT_DT_TM >= (SYSDATE-730)) AND FORMATTED_MEDICAL_RECORD_NBR IN (SELECT FORMATTED_UAB_MRN FROM REGISTRY_PATIENT WHERE REGISTRY_ID=2861)
| ||
| Encounter Intervention | Encounters matching the appended SQL criteria are added to the registry AND candidate is flagged for review | AND SRC_ADMIT_DT_TM >= (SYSDATE-30) AND ( (reason_for_visit_txt LIKE '%COPD%') OR (UPPER(reason_for_visit_txt) LIKE '%BRONCHITIS%') OR (UPPER(reason_for_visit_txt) LIKE '%BRONCHIECTASIS%') OR (UPPER(reason_for_visit_txt) LIKE '%EMPHYSEMA%') ) | ||
| PHEDRS MetaData CV | 24 | Patient Review Cutoff Date | Do not retrieve any data (codes, encounters, documents) from source system before this date | 1/1/17 |
| Registry Application Title | Use this text here for the name of the registry | COPD Registry Control Panel | ||
| Display Codes Database Identifier | DB_ID permissable to display in "Diagnoses and Drgs" Panel | 8 | ||
| PHEDRS Tab CV | 25 | REGISTRY_INPATIENT_REVIEW | Indicates that this tab should be displayed in this registry. Value indicates display order from LEFT to RIGHT (1 for leftmost tab) | 1 |
| Optum UAB APR DRG Codes 2017 | 26 | |||
| UAB WH CLN REF Codeset 69 | 27 |
Developer Guide to PheDRS Data Loading Criteria
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"
| 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" | |
| 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 | |||
| Candidate | ANY | ANY | NO CHANGE | NO CHANGE | ANY | Ignore diagnosis criteria on accepted patients | ||||
| NLP_Detection | NLP_HITS_EXTENDED contains CUI with detection criteria | NULL | NULL | NULL | CANDIDATE | NEVER REVIEWED | ANY | Add candidate | CVTERMS corresponding to registries have a CVTERMPROP set on them with cvterm_id (registry_id), type_id (cvterm in NLP Pipeline Parameter Ontology) with value containing a UMLS CUI | |
| Provisional | ANY | ANY | NO CHANGE | NEEDS REVIEW | ANY | Flag rejected and provisional candidates for review | C98764323,C0012345,C0654321 | |||
| Candidate | ANY | ANY | NO CHANGE | NO CHANGE | ANY | Ignore detection criteria on accepted patients | Multiple CUIs are supported as additional rows in CVTERMPROP. Contextual CUIs are supported via commas | |||
| NLP_Intervention | NLP_HITS_EXTENDED | ANY | ANY | Requires Intervention | NO CHANGE (CANDIDATE IF NULL) | NO CHANGE | NO CHANGE | CVTERMS corresponding to registries have a CVTERMPROP set on them with cvterm_id (registry_id), type_id (cvterm in NLP Pipeline Parameter Ontology) with value containing a UMLS CUI | ||
| contains CUI with | ANY | ANY | Intervention Complete < Encounter Date | NO CHANGE (CANDIDATE IF NULL) | NO CHANGE | Requires Intervention | C98764323,C0012345,C0654321 | |||
| intervention criteria | ANY | ANY | Any other current valid cvterms | NO CHANGE (CANDIDATE IF NULL) | NO CHANGE | Requires Intervention | Multiple CUIs are supported as additional rows in CVTERMPROP. Contextual CUIs are supported via commas | |||
| ANY | ANY | Intervention Complete > Encounter Date | NO CHANGE (CANDIDATE IF NULL) | NO CHANGE | NO CHANGE | Compare date of code/encounter with the end(if not null) or start_date of the REGISTRY_PATIENT_CVTERM entry | ||||
| Inclusion (Code Inclusion) | PATIENT_CODE entry that matches inclusion criteria in CVTERMPROP | All except Accepted | ANY | ANY | ACCEPTED | NEEDS REVIEW | DRG Codes generate automatic registry inclusion | |||
| Accepted | ANY | ANY | NO CHANGE | NEEDS REVIEW | ||||||
| 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… :) | |
| MACHINE_ACCEPTANCE_SCORE in REGISTRY_PATIENT | ||||||||||
| is set to a non-zero value | ||||||||||
| Code_Collection | None (daily) | Candidate | ANY | ANY | NO CHANGE | NO CHANGE | NO CHANGE | Specify data to collect for the registry | CVTERMPROP has cvterm_id (registry_id) and type_id (data source) and value which is a regular expression specifying code_values to collect from REGISTRY_PATIENT_CODES | |
| Accepted | ANY | ANY | NO CHANGE | NO CHANGE | NO CHANGE | Do not collect data unless patient is in registry | ||||
| Encounter Collection | None (daily) | 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 | |
| Accepted | ANY | ANY | NO CHANGE | NO CHANGE | NO CHANGE | REGEX | REGEX…. | |||
| 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 | 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 | ||||
| Encounter Detection | None | Encounter | ||||||||
| Document Loading (deprecated) | Existence of documents | 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 |