Overhaul entities sample to use new schema guidelines

[kmoscoe]

Running at http://bullie.svl.corp.google.com:8080

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request updates the sample entity data and schema definitions to comply with new project-wide schema guidelines. The changes involve restructuring the MCF files and updating the corresponding CSV data entries to ensure alignment with the new naming conventions and data modeling standards.

Highlights

• Schema Migration: Updated entity definitions and statistical variables to align with new schema guidelines, including the migration from 'variables.mcf' to 'schema.mcf'.
• Data Normalization: Renamed variables in the CSV data to match the updated schema definitions for better consistency and readability.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the Alaska hospitals unplanned visits dataset and its schema. It renames the variables in the CSV file to use more descriptive names (e.g., changing EDAC_30_AMI_TOTAL to Count_Patients_HeartAttack) and introduces a new schema.mcf file that models these variables using structured classes and properties. A review comment correctly points out a typo in schema.mcf where measuredProperty is incorrectly defined as dcid:cma/medicalCondition instead of dcid:medicalCondition.

[carojahn]

Left one comment - not strongly opinionated but curious to get your take on why you made it a separate populationType

[kmoscoe]

Left one comment - not strongly opinionated but curious to get your take on why you made it a separate populationType

[carojahn]

I am assuming that these StatVars without Patient are the count of "heart attack occurrences"? While something like "count_patients_heartattack" measures the actual number of patients?

Wondering if there is a need to aggregate across all diseases for "count_heartattack_returnpatients" and others, in which case an alternative could be "count_medicalcondition_returningpatient_heartattack". Not strongly opinionated but curious how we'd justify the condition as a constraint in one and populationType in the other.

[kmoscoe]

No, both of these measures just record the actual number of patients, both returned and not returned. The actual EDAC (excess days in acute measure), which is the principal measure, and measures just the additional days of the returned patients, is not included here. Maybe I should do so to make it clearer, WDYT?

[kmoscoe]

(The original naming I used was actually misleading.)

[kmoscoe]

BTW, the CMS keeps those 3 medical conditions as separate metrics. So I think they're not being compared to anything else.

[kmoscoe]

Yeah, in fact the EDAC is really the primary measure: https://qualitynet.cms.gov/inpatient/measures/edac. The patient counts are more like "additional info". So I definitely need to rework this. Thanks a lot for pointing it out -- not sure what I was thinking!

[kmoscoe]

OK, I've now added new statvars for the actual time measurement. It made more sense to keep regular patients and return patients as separate classes because the duration metrics only relate to return patients.

[gmechali]

good from my perspective.

[carojahn]

discussed offline, single enum for a constraint property doesn't make sense.