PheDRS: Difference between revisions

From Cheaha
Jump to navigation Jump to search
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
| 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 ==
The evidence code ontology is used to describe how a patient's status in the registry (ACCEPTED, REJECTED, CANDIDATE OR PROVISIONAL) has been decided.
{| class="wikitable"
|+ Evidence Code
|-
! Name
! Short form
! Interpretation
|-
| Referred
| REF
| Current patient registry status has been assigned manually
|-
| Algorithm Discovered Patient
| ALG
| Current patient registry status assigned by an algorithm
|-
| NLP Discovered Patient
| NLP
| Current patient registry status has been assigned on the basis of NLP processed text.
|-
| Code discovered patient
| DIAG
| Current patient registry status has been assigned on the basis of a structured code, ex) ICD-10-CM
|-
| Encounter Discovered Patient
| ENC
| Current patient registry status has been assigned on the basis of an encounter
|-
|}
|}



Revision as of 20:39, 24 January 2019

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.

Registry Property Descriptions and Examples

Registry Configuration: Cvtermprop parameters
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 MACHINE_ACCEPTANCE_SCORE in REGISTRY_PATIENT is set to a non-zero value Custom registry specific implementation that should result in a publication… :)
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 (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
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
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


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.

Evidence Code
Name Short form Interpretation
Referred REF Current patient registry status has been assigned manually
Algorithm Discovered Patient ALG Current patient registry status assigned by an algorithm
NLP Discovered Patient NLP Current patient registry status has been assigned on the basis of NLP processed text.
Code discovered patient DIAG Current patient registry status has been assigned on the basis of a structured code, ex) ICD-10-CM
Encounter Discovered Patient ENC Current patient registry status has been assigned on the basis of an encounter

Back End Workflow / Architecture

Web Service Documentation

RegistryWS

UDAS

Paper References