HughesRiskApps: Risk Assessment beyond breast/ovarian cancer

HughesRiskApps (HRA) was originally developed to better identify and manage patients at high risk of developing breast cancer and/or of needing genetic testing for hereditary breast/ovarian cancer syndrome.

Many of the approaches and infrastructure were designed with the intention of extrapolation into the identifying and managing patients at risk for other benign and malignant conditions.

We will consider the possibilities for extrapolation by considering the component parts of HRA, which include, but are not limited to:

1. Data pulled from existing sources2. Patient entered data (using TabletPCs, iPads or Websites)3. Clinical Decision Support to identify possible issues to be addressed4. Printing of structured reports for clinicians and information sheets for patients (e.g.,

Smoking cessation information if the patient records that they currently smoke)5. Clinician review, verification and enhancement of patient entered data6. CDS at the clinician level using the added information7. Printing of documents (H&P, Consult letters, Consent forms, etc)8. Summary Reports and statistics 9. Queue Function

This approach and flow can apply to any disease or disease risk.

Data pulled from existing sources

Medicine is known for a huge amount of redundant data entry. This increases workload for clinicians and staff, and generates errors of omission, misinterpretation and incorrect transcription. To help to decrease redundancy, HRA is able to pull data from existing sources. For example, HRA can pull medications, allergies, reports, labs, etc. from the Partners Healthcare EHR for all patients being seen on a given day.

Patient entered data (using TabletPCs, iPads or Websites)

The HRA data collection system is easily modified to use any set of questions required by the clinical situation. HRA has questionnaires for prenatal genetics, for breast cancer risk, and for colon cancer risk, to name a few. Basically, if a set of questions can be conceived for determining risk for a given condition, creating this questionnaire in tablet format is relatively trivial.

In addition, the branching logic capability allows creation of extensive surveys that can be completed in a short time. For example, a questionnaire may have 100 questions addressing 5 separate conditions, but by asking a few simple questions up front to determine which syndromes are possible the patient might only see 20 or 30 of those questions. For example, if a patient denies heart disease in the family, several questions about which relatives have heart disease will not be seen by the patient. Or if a patient has never taken hormone replacement therapy, questions about duration and type will not be displayed.

The result of well crafted surveys is effective and efficient data collection.

Clinical Decision Support to identify possible issues to be addressed

CDS is the application of algorithms, guidelines, and machine readable medical knowledge against a computerized data set to determine possible diagnoses and suggested interventions. HRA has developed extensive CDS for breast cancer risk, running multiple risk models and applying consensus guidelines to the results. Extrapolating the approach and lessons learned to other specialties is possible when there is the participation of a domain expert. HRA has used its expertise in software to team up with experts in prenatal genetics, PreAnesthesia evaluation, and other clinical situations to develop CDS in various clinical areas.

Adding in new models or guidelines is well supported by the software design. The input of a domain expert is vital to creating the best CDS possible.

We have CDS for breast/ovarian cancer, with multiple models and robust cds for its management. We have robust CDS for determining what genetic tests are needed in the prenatal setting.

This CDS could be expanded to include more syndromes with the appropriate domain expert.

Some of HRA's breast cancer CDS risk screens are shown here:

We have rudimentary beginnings for colorectal but need to buff up the colorectal models (PREMM and MMRPRO) and the CDS of management.

We have begun to develop our ASK2M (All Syndromes Known To Man) for all adult cancers, which we plan to expand to benign diseases as well.

The algorithm is rudimentary at this time. It has links to GeneTest and OMIM to give the clinician more information about each syndrome and how to test for it.

Printing of structured reports for clinicians and information sheets for patients (e.g., Smoking cessation information if the patient records that they currently smoke)

Patient entered data is collated with downloaded data from the EHR and results of CDS to create an informative document for the clinician and a tailored set of information sheets for the patient. This has been done in various specialties and is easily extrapolated to other genetic and non-genetic diseases.

Clinician review, verification and enhancement of patient entered data

The interface for clinicians must be intuitive and germane to their clinical needs. We have built a clinician interface for genetics, for rheumatology, for breast surgery and other areas. Customizing an interface is easily accomplished.

In terms of genetics, the most important features are the family history, its representation as a pedigree and the ability to add manifestations and genetic test results to specific individuals.

This has been well mapped out and implemented for hereditary breast/ovarian cancer, but has been done with an eye to extrapolation.

The entry of manifestations and testing is set by groupings. When the breast grouping is chosen all cancers show up as manifestations to add, and in genetic testing, breast panels are shown.

In the cardiac grouping, all cardiac diseases show up as manifestations, and in genetic testing, cardiac panels are shown.

The active user determines which grouping is shown at startup, but any user can use any group.

We plan also to alter the display by user, so that the pedigree displays cardiac diseases prominently while fading the cancers for cardiac users, and doing the opposite for cancer users.

One current weakness is that our genetic testing and pedigrees are optimized for autosomal dominant diseases. We plan to adjust our data structure and interface to manage recessive diseases and SNPs. This is a small change in the database. It will require a different set of queries to interpret multiple alleles or SNPs, and a knowledge base to allow interpretation, but the structure has been partially mapped and could be implemented with minimal difficulty.

CDS at the clinician level using the added information

CDS after clinician edits is similar to the earlier CDS, but now uses the added information from the clinician. For example, in studying hypercholesterolemia, the cholesterol level might be downloaded from the EHR or entered by the clinician, and this could then be used in the CDS.

Printing of documents (H&P, Consult letters, Consent forms, etc)

We have developed well crafted letters to referring clinicians that describe the interactions of a hereditary breast /ovarian cancer consultation. We have developed similar letters for breast surgery and other specialties. Changing these letters and documents (Letters of medical necessity, consent forms, etc ) for different genetic conditions will require a domain expert for content, but the infrastructure already exists.

Summary Reports and statistics

The report function provides precanned reports for various clinical situations. Extrapolating this approach to other diseases will require a domain expert. The infrastructure already exists.

Queue Function

Queue function provides views of specific patients who need specific management, helping the counselor organize further follow-up, or track patients at high risk not yet seen at the risk clinic:

Monitor positive families to confirm maximum uptake of tests by family members

The Queues can be developed for any manifestation or any syndrome. The infrastructure already exists and is easily extrapolated.