Heart Failure (HF) with Differentiation between Preserved and Reduced Ejection Fraction

Primary tabs

Unstructured Data: 
NLP
Structured data: 
CPT
ICD9
Data Source/clinical domain: 
observations
medications
Files: 
HF Validation Spreadsheet.xlsx
Liu_CRI2013_0121_revised.pdf
Heart Failure Validation Guidelines 11132013.docx
Data Dictionary for Case/Non-Case Algorithm
Pseudo Code for Case/Non-Case Version of Heart Failure Algorithm
Pseudo Code for Cohort Version of Heart Failure Algorithm
Data Dictionary for Cohort Version of Heart Failure Algorithm
Information
Phenotype ID: 
147
Date Created: 
Sunday, February 24, 2013
Status: 
Final
Do Not List on the Collaboration Phenotypes List
Contact information
Contact Author: 
Sue Bielinski
Authors: 
Suzette J. Bielinski
Institution: 
Mayo Clinic
Network Associations: 
eMERGE
View Phenotyping Groups: 
eMERGE Phenotype WG
Owner Phenotyping Groups: 
eMERGE Mayo Group
Demographics
Gender: 
Female
Male
Age: 
Adult
 

Suggested Citation

Suzette J. Bielinski. Mayo Clinic. Heart Failure (HF) with Differentiation between Preserved and Reduced Ejection Fraction. PheKB; 2013 Available from: https://phekb.org/phenotype/147

Comments

Hi,

Any information on when the HF NLP system will be availble, or if it is ready now where we can download it?

Thanks,

David

1) in 1 of our main systems ICD-9 codes are what is recorded in the Problem List (PL); thus, should we look for ICD-9 codes 428.* to find pts meeting the PL part of the case criteria?

 

2) In some of the echo results there is no numeric EF (ejection fraction), only a descriptive word such as: normal/abnormal, low/moderate/severe, or reduced/decreased.  This occurs for ~1,000 of our ~2,000 genotyped pts w/ EF measures, of which ~100 pts only have this type of result.  How would you want us to categorize these cases, if they turn out to be cases otherwise?  i.e., if normal then type 2, else throw them out?

Thanks!

Jen

Hi,

When conducting manual chart review validation of heart failure cases, if the manual review confirms that the patient has HF but the **index date** identified by manual review differs from the index date identified by the automated algorithm, how do you want us to classify this case for validation purposes (confirmed by manual review or not confirmed by manual review)? Does it matter how much difference there is between the two index dates, and if so, how much it too much of a difference?

Thanks,

David

We took a rather liberal approach as we found this as well.  If the dates were reasonably close (arbitrary) w/i a year we accepted.  As heart failure is a syndrome and exact date is not critical.

I saw this moved from Testing to Validated, but I don't see any validation results.  Has GHC, the secondary site, completed it's

validation?  Is this ready to be implemented by the Network?

Thanks,

Jacqueline

 

 

Our validation is uderway.  Controls validatated with a PPV of 100% (random sample of N=25 subjects).  Cases are being validated now.  Six of 27 charts selected for validation have been completed and all of them validated.  Keeping fingers crossed for the remaining cases.

-David

In the Excel data dictionary, please specify an"as of" date for vital status (which is coded as alive or dead).  Is it Case Date?  Data pull date?  etc...

Thanks

 

  VITAL STATUS Vital Status of Subject C37987 Alive
C28554 Dead

Is it correct to interpret:

"Lowest EF measured 6 months after the HF date."

as

 the lowest Ejection fraction measured 0-6 months after the HF_date

 

I just wanted to confirm about two situations for determining ejection fractions:

 

1.  In our documents we have instances of "Normal" instead of a numeric value.  If this is the qualifying EF, so we consider it Case type 2?

2.  In our parsing algorithm, if there is a range for EF, eg 40-55, we take the average of the range as the EF value.  Will this work for this algorithm?  Note, if we need to change this, this will involve alot more effort to completing this.

 

Thanks,

Jacqueline 

Yes for both questions.  Consider as case 2 for those with normal listed and average when a range is provided. 

Thanks

Sue

1. For the BMI file, you ask for Weight in Pounds and Height in inches, but the dd standard in eMERGE tends to have this sent as kg and cm.  Is there a reason you changed this? Do you need us to covert this, or can we send as kg and cm?

2. For HF_MI_Rep_measurement - I am confused by this formate.  We may have multiple dates for each ICD type.  I am not sure how you are wanting a row to be lined up?  Because for example I may have 5 410s, 2 412s, 1 413, and no 414, how should this be represented?

OR should we send a ICD file with id, ICD code name, and ICD date for icds in your list?

Thanks, 

Jacqueline

 

1. LAST_FU_DATE - We don't have followup data as a structured field.  How are you defining this?  Follow-up from EF?  If so, which one?  Or just last date of some clinic visit?

2. For EF, you say you want this field of be an interger.  Our EF data has alot of things in it that are not just #, eg. "Normal" or ranges or some > some value.  Do you only want integer EFs or should we send everything?

Thanks, 

Jacqueline

 

 

1.  For FU, groups are either using a date from registration or last encounter/visit date. 

2.  Integer prefered - if a range is given, provide only the lowest number.  If the only EF listed is normal, then indicate that - these patients will be considered Type 2 HF (normal = EF > 50%).

 

 

I have upload new versions of the data dictionary and pseudo code that address the issue of ejection fraction (EF) results being only reported as free text (e.g. normal/abnormal).  Furthermore, units for weight and height were changed to kg and cm per eMERGE standard procedure. 

 

Thanks

 

Sue

Hi,

Can you please provide RAW VALUE and FORMATTED VALUE specs in the data dictionary for all fields?   Examples where these specs are missing are HF_INDEX_DATE, HF_INDEX_EF (among others) in the HF_SUBJECT table (but the specs are missing from other tables too).

Thanks!

 

 

Meant to suggest ISO 8601 format as a standard for representing calendar dates as strings (e.g,. today's date would be the string "2014-04-15").

 

 

 

 

We have streamlined the data dictionaries to limit to those variables needed in the GWAS analsyes.  Everything has been updated on PheKb

We edited the Data dictionary to allow for missing values of EF per the phentoype meeting 8/3/2016.  The values are still required but for those with missing data please code as follows. 

.=missing/unknown/unassessed/non-applicable