Clearly list and define each information type the algorithm extracts (entities, relations, attributes, and document-level classes), including scope and granularity. Specify whether concepts are atomic or multi-part, what modifiers are captured (e.g., negation, temporality, certainty), and provide concrete examples for each type.

Describe the clinical framework guiding extraction (or explicitly state that none is used), including version and clinical purpose. Justify why this framework fits the use case, document adaptations and assumptions, define inclusion/exclusion criteria for concepts, and report limitations that may affect interpretation.

Describe the technical data model used to represent extracted outputs (e.g., OMOP, FHIR, custom JSON), including version. Explain why it was chosen, how concepts map to concrete fields/resources/tables, any transformation steps between formats, and whether custom schemas are available.

Explain how extracted entities are normalized to terminologies/ontologies/thesauri (e.g., SNOMED CT, ICD, UMLS, RxNorm). Report the linking method, disambiguation strategy, and handling of unmapped concepts so semantic interoperability and comparability can be assessed.

If applicable, describe how complementary clinical context is handled: uncertainty, negation, temporality, ambiguity, inconsistency, and coreference (patient vs. family/other). Report the methods, labels, and decision rules used to ensure extracted facts reflect the true clinical meaning.

Define the primary extraction task(s) and any auxiliary tasks in the pipeline (e.g., classification, NER, relation extraction, template filling, summarization). For multi-step or agentic workflows, describe each step, its objective, and how outputs flow between steps.

Detail implementation strategy, frameworks/libraries with versions, model checkpoints, pipeline orchestration, and key parameters. For complex systems, include architecture decomposition; for LLM-based systems, reference model card information and prompt/pipeline versioning.

Describe all text normalization and cleaning operations before model input (e.g., casing, punctuation, diacritics, abbreviation handling, tokenization, segmentation). Include tools, versions, parameters, and rationale for each step so preprocessing choices are reproducible.

Report all training and inference hyperparameters and how they were selected (manual, grid/random/Bayesian search, CV, validation split). For in-context learning, provide exact prompt templates, few-shot selection strategy, and confirm development did not use test data.

Report hardware used for training and inference (device model/count, vRAM, RAM/CPU, cluster context), computational budget (GPU/CPU-hours), and costs if available. Distinguish training from deployment-like inference environments to support feasibility assessment.

Provide a step-by-step data flow from the original corpus to final analysis set, including selection, exclusion, filtering, sampling, de-identification, and preprocessing. Report counts after each step (documents/sentences/tokens) and reasons for losses; include a flow visualization when possible.

Describe the complete splitting strategy (train/validation/test/eval), split unit (patient, note, encounter, sentence), modality (random, stratified, temporal, grouped), and counts per subset. Clarify anti-leakage constraints and cross-validation settings if used.

State where texts originated: department(s), institution(s), country/region, and whether the data are single-site or multisite. If relevant, include source systems/platforms (EHR, data warehouse, repository) used to extract the text.

Describe document type(s), author role(s), care-stage timing (admission, inpatient, discharge, follow-up), intended purpose, and typical structure/content. If multiple note/report types are included, describe differences that may affect extraction behavior.

Specify the study timeframe (start/end dates), temporal granularity/binning, and distribution over time. Report major practice/system changes across periods that could alter language, labels, or model behavior.

Describe the target population represented by the dataset and key representativeness limitations. Report class distributions at source/sample/split levels and methods used to handle imbalance (e.g., stratification, sampling, class weighting).

If applicable, specify examination type(s) and associated medical specialty(ies), including distribution when multiple domains are included. Note specialty-specific terminology/structure and implications for extraction complexity and generalizability.

Specify language(s) used in development and evaluation, including relevant regional variants where important. Describe any language manipulation (translation, normalization across dialects), tools used, and potential impact on performance.

State whether ethics/IRB approval was obtained, including committee name and reference/protocol number where applicable. Report relevant provisions such as informed consent status or waiver conditions.

Describe whether annotation is manual, rule-based, ML-based, or hybrid, and the exact sequence in the workflow. Include tagging format (e.g., IOB2/IOBES/inline), role of automated pre-annotation, and reproducibility constraints tied to rules/models.

Detail the annotation process: annotator background, roles, training/calibration, number of annotators, pilot rounds, and adjudication. Explain independent vs collaborative annotation and how process design supports reliability.

Describe annotation guidelines content and how they were created, piloted, revised, and versioned. Clarify treatment of ambiguous/borderline cases and explicitly state whether guidelines are publicly available (with location if available).

Name software tools used for guideline development and annotation, including relevant configuration decisions that affected workflow or quality. Briefly justify tool choice (e.g., security constraints, relation support, collaboration features).

Report how annotation consistency was measured, including metric(s) used (e.g., kappa, alpha, agreement F1), setup, and achieved agreement levels. Explain how disagreements were resolved and how final labels were established.

Report per-information-type performance and aggregated metrics, with explicit aggregation method (micro/macro/weighted). Justify chosen metrics, provide calculation formulas, include confusion matrices where relevant, and summarize manual error analysis and baseline/human comparisons.

Describe statistical validation procedures used to support reliability of findings (assumption checks, diagnostics, uncertainty estimates, significance tests, confidence intervals, cross-validation/bootstrapping as appropriate). Report methodological constraints and violations.

If performed, report external validation on independent data from other institutions, including dataset characteristics and differences from internal data. Use comparable metrics and document any adaptation steps; if not feasible, state this clearly as a limitation.

Provide a clear data availability statement: public, request-based, or unavailable, with rationale. Include repository/DOI or access conditions/contact and note availability of related reproducibility artifacts (e.g., preprocessing scripts, synthetic/derived data).

State whether source code is available and provide stable, citable repository links plus experiment version identifiers (tag/commit). If applicable, provide trained model links and reproducibility instructions; if unavailable, explain constraints and alternatives for verification.