Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTAN2 Clinical Update Design and RFC #472

Open
aclayton555 opened this issue Dec 17, 2024 · 4 comments
Open

HTAN2 Clinical Update Design and RFC #472

aclayton555 opened this issue Dec 17, 2024 · 4 comments
Assignees
Labels

Comments

@aclayton555
Copy link
Contributor

24-11/12 Sprint Kick-Off Discussion - What is needed for clinical data in HTAN2?

Kristen:

  • Solid core clinical model that captures what CRDC needs (i.e. what standards they are landing on for the CRDC Submission Portal).
  • Need to get through clinical object classes, identify changes needed. Reflect on what was captured in HTAN1 and what we need to change.
  • Need to decide on proposed changes and what format this should take
  • Core model should have extensions for cancer-specific elements for new centers
  • Include linkages to accession numbers with permissible values

Adam:

  • Core model - what form does this take. A component like “HTAN Clinical Core” that is required, with optional additional templates. Currently, core is limited to demo and diagnosis, but is that sufficient?
  • Want a core model to compliment how folks are generating data
  • Definitely want core to be 100% required, and mappable to CRDC/CDS.
  • Coded attributes - has been a pain point in HTAN1. Kristen has thoughts on this...CDS is using uberon ontology - but no one uses this in practice. Propose we use ICDO code and populate primary diagnosis that goes with that code. But need to account if there are specific difference between code and diagnosis. Let CDS deal with mapping to uberon ontology

TL; DR -Kristen has been digging into this and will focus this sprint on design. Several conversation with CRDC stakeholders throughout December to align on standards in use and anticipated mapping.

@aclayton555
Copy link
Contributor Author

24-11/12 Close-out: Ongoing clinical core model design

  • RFC has been written; need to update to include tiers. Will include some shift to Tier 1 (about 18 elements) vs Tier 2 (about 12 elements), and likely moving some elements to biospecimen. Biospecimen is next.

Some considerations:

  • Structure as a flatter, single template? Tier 1 as fully required, and include Tier 2 optional attributes within this. Keep Tier 3 as additional, potentially Atlas-specific attributes that are flexible

  • Consolidate demographics and diagnosis? This would be large. Clinical Tier 1 vs diagnosis - chunking allows for more logical data organization and submission. But there may still be room to consolidate this…would this maybe be easier for downstream portal and CDS usage, as these are typically consolidated into single large tables (i.e. User flow is flat, but database architecture has them separate and joined as needed. Need to also consider how longitudinal data may impact this

  • Aim to get this down to 3ish templates (currently 7 or 8)

Next steps:

  • Kristen will finalize this RFC this week and circulate for initial DCC feedback with this group
  • Will also mark where we need validation

@aclayton555 aclayton555 changed the title HTAN2 Clinical Update Design HTAN2 Clinical Update Design and RFC Dec 17, 2024
@aclayton555
Copy link
Contributor Author

25-1 Kick-Off - see email from Kristen on Jan 5 with links to Clinical RFC. Includes details of proposed Tier 1 Demographics and Diagnosis elements, as well as the start of Tier 2.

Initial feedback requested from @adamjtaylor (assigning this ticket to Adam for now) @aditigopalan and @PozhidayevaDarya

Kristen will pick this back up once back in the office on Jan 22.

@aclayton555
Copy link
Contributor Author

In clinical data update, review: https://sagebionetworks.jira.com/browse/HTAN-594

Do we still have Days to Vital Status Reference and if so, do we need to add 'Not applicable' as a PV?

@kristenanton
Copy link

We will continue to use clinical data update for post-baseline updates.
We do not need to add 'Not Applicable' to Days to Vital Reference Status. This will always be the 'days to' the date of last contact with the patient or date of last information about the patient. If there is no contact post baseline, then the value will be days to the date of baseline. Should always be an integer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants