Evidence-Based Temporal Reasoning for Generalizable Longitudinal EHR Question Answering
Evidence-Based Temporal Reasoning for Generalizable Longitudinal EHR Question Answering
Abstract
Longitudinal electronic health record (EHR) question answering remains difficult because clinically meaningful evidence is distributed across visits, data models, and document types, while many user questions depend on sequence, timing, and provenance rather than on isolated facts. Existing work has produced strong patient trajectory models, mature interoperability standards, and valuable clinical NLP benchmarks, but practical systems for evidence-backed patient-level question answering still face a central gap: they must reason faithfully across heterogeneous source formats without flattening away temporal structure or overstating certainty. We present an agent-centered workflow for longitudinal EHR question answering that treats harmonization as a reviewable reasoning surface rather than a one-shot preprocessing step. The workflow supports FHIR, OMOP, and mixed local chart exports; separates reusable patient-level artifacts from question-specific workspaces; constructs visit-centric timeline packages with structured tables and XML event timelines; and reserves ambiguous timestamp inference, visit assignment, and evidence adjudication for explicit review. It combines script-assisted staging, provenance-preserving packaging, deterministic code execution for auditable subproblems, and reflection-driven validation before answer synthesis. Package-grounded case studies illustrate three representative tasks: whole-record longitudinal summarization, encounter-bounded medication identification, and chart-relative temporal aggregation. Across these examples, the central result is conceptual: evidence-based temporal reasoning is not a peripheral enhancement but the main mechanism that makes longitudinal EHR question answering trustworthy, reusable, and extensible toward future interactive systems such as "Chat with EHR."
Introduction
The modern EHR is not a single document. It is a time-varying clinical archive composed of encounters, orders, measurements, medications, procedures, microbiology, radiology, notes, and external artifacts whose timestamps may be incomplete, conflicting, or only indirectly stated. Clinicians interpret this archive longitudinally: they decide which timestamps are trustworthy, which documents belong to the same clinical episode, which events were charted late, and which claims are supported strongly enough to use. Many computational pipelines, in contrast, still prefer representations that are easier to normalize than to reason over temporally.
This tension is visible across several strands of biomedical informatics. Predictive modeling over EHR sequences has advanced from recurrent architectures such as Doctor AI and RETAIN to transformer-based models such as BEHRT and Med-BERT, showing that patient trajectories contain rich temporal signal for diagnosis and risk prediction [1-4]. Interoperability efforts such as OHDSI and SMART on FHIR have made common data models and substitutable applications more practical across institutions [5,6]. Large-scale modeling over raw FHIR-like records has further shown that broad clinical context can sometimes be preserved without extensive manual feature engineering [7]. At the same time, clinical NLP has long shown that temporal extraction is important but hard, from the 2012 i2b2 temporal relations challenge to Clinical TempEval [8,9], and emrQA demonstrated the scale and complexity of question answering over clinical records [10].
Recent work from 2024-2026 has intensified interest in this space. A 2024 scoping review found that EHR question answering research remains fragmented across datasets, tasks, and evaluation strategies [14]. EHRAgent showed that code-enabled agents can improve complex tabular reasoning over EHR data [15]. Low et al. reported in 2025 that real-world clinical question answering benefits substantially from retrieval-augmented and agentic systems rather than generic foundation models alone [16]. Recent preprints such as Traj-CoA, EHR2Path, and HeLoM also suggest a broader shift toward long-context, pathway-level, and memory-aware modeling of patient trajectories [11-13]. Together, these studies make the opportunity clear, but they also reinforce a persistent gap: generalizable patient-level QA still lacks a robust temporal substrate that is reusable across questions, faithful to provenance, and honest about ambiguity.
That gap matters because many clinically meaningful questions are neither purely predictive nor reducible to note-level QA. Users ask questions such as: What was the last drug prescribed during the first hospitalization? Which medications were prescribed in the last 13 months of chart activity? How did this acute hospitalization evolve from emergency presentation through intensive care and discharge? These are temporal, evidentiary, patient-specific questions. They require more than schema conversion, more than retrieval over unstructured text, and more than sequence modeling for future prediction.
This paper describes a workflow designed around that requirement. The central hypothesis is that trustworthy longitudinal EHR QA emerges not from forcing every source into a single final schema, but from a layered process in which harmonization, temporal review, deterministic calculation, and answer synthesis remain separable, inspectable, and reusable. The contribution is methodological rather than benchmark-centric. We describe the end-to-end workflow, explain the contracts that make it reusable across repeated questions, and present case studies from bundled de-identified chart packages showing how evidence-based temporal reasoning changes both the process and the answer.
Related Work
Patient trajectory modeling
Patient trajectory modeling has become a central paradigm for EHR AI. Doctor AI showed that recurrent neural networks can learn next-visit diagnoses and medications from longitudinal records and transfer across institutions [1]. RETAIN introduced reverse-time attention to improve interpretability while preserving competitive predictive performance over visit sequences [2]. BEHRT and Med-BERT extended this line of work by adapting transformer-style pretraining to structured EHR data, strengthening downstream performance and showing the value of large-scale longitudinal representation learning [3,4].
Recent work has pushed farther toward long-context and memory-aware trajectory processing. Traj-CoA proposed a chain-of-agents architecture in which worker agents process temporal chunks sequentially and populate a shared memory module before a manager agent synthesizes the final prediction [11]. EHR2Path framed patient pathway modeling as a scalable longitudinal representation problem using summary tokens and pathway-level prediction [12]. HeLoM explored memory-augmented longitudinal reasoning for heterogeneous EHRs under limited public-data conditions [13]. These studies support the importance of pathway-level modeling, but they remain centered on prediction and simulation rather than on patient-specific, evidence-cited question answering.
Interoperability and common data models
FHIR and OMOP solve a different but complementary problem: how to make heterogeneous health data more analyzable and more portable. OHDSI established the value of a federated ecosystem built around a common observational data model [5]. SMART on FHIR made standards-based substitutable applications over EHR data a practical architectural target [6]. Rajkomar et al. showed that multi-center EHR data represented in FHIR-like form can support strong predictive performance without exhaustive site-specific feature engineering [7].
These contributions are foundational, but they do not remove the need for case-level temporal adjudication. Even nominally structured records still contain delayed documentation, partially linked medications, nested encounters, document metadata that conflicts with content, and mixed local exports that are only partly FHIR- or OMOP-shaped. Our workflow therefore treats FHIR and OMOP as supported source formats rather than mandatory final reasoning targets.
Clinical temporal reasoning and EHR QA
Clinical NLP has long recognized that time is central to understanding patient records. The 2012 i2b2 temporal challenge and the later Clinical TempEval task formalized extraction of temporal expressions, events, and relations from clinical narratives and showed that temporal linking remains harder than entity recognition alone [8,9]. emrQA then demonstrated the scale and complexity of question answering over clinical records by deriving a large QA corpus from expert annotations [10].
More recent work has sharpened the distinction between benchmark QA and real-world clinical workflows. Bardhan et al. showed in 2024 that EHR QA remains fragmented across data sources, answer formats, and evaluation paradigms [14]. EHRAgent demonstrated in 2024 that code execution can materially strengthen few-shot EHR table reasoning [15]. Low et al. found in 2025 that real-world clinical questions were handled far better by retrieval-augmented and agentic systems than by general-purpose LLMs alone [16]. At a broader medical QA level, Med-PaLM 2 showed that expert-level long-form answering is increasingly plausible, although not specifically grounded to an individual patient chart [17]. A 2025 systematic review of retrieval-augmented generation in healthcare similarly emphasized grounding and evidence linkage as first-order design concerns [18].
This literature motivates the present workflow in three ways. First, temporal understanding cannot be treated as a solved preprocessing problem. Second, question answering over note text is not the same as longitudinal question answering over multimodal patient records. Third, newer agentic and retrieval-grounded systems are promising, but they still require a patient-level temporal substrate that is reusable across questions and explicit about uncertainty.
Methods
Design goals
The workflow was designed to satisfy six requirements spanning harmonization, temporal reasoning, and question answering.
First, it must support heterogeneous inputs without requiring a single whole-case converter. A patient record may arrive as clean FHIR resources, OMOP tables, or a mixed export containing CSV, JSON, XML, plain text, and PDFs. Second, it must preserve temporal structure in a form legible both to scripts and to a reviewing agent. Third, it must support temporal adjudication as an explicit reasoning step, so that ambiguous timestamps, overlapping encounters, and weak document metadata can be challenged rather than silently accepted. Fourth, it must support question-aware retrieval, allowing summary questions and search questions to follow different evidence paths over the same patient timeline. Fifth, it must allow deterministic code execution for auditable subproblems such as ranking, filtering, time-window calculation, and cross-file reconciliation, consistent with recent code-enabled EHR reasoning systems [15]. Sixth, it must support repeated questions over the same patient without recomputing the entire trajectory each time while keeping provenance, assumptions, and unresolved items visible.
Workflow overview
Figure 1 summarizes the end-to-end workflow. The key design principle is that helper scripts accelerate staging and packaging, but the final temporal interpretation remains reviewable.
flowchart TD
A["Input patient record<br/>FHIR, OMOP, or mixed export"] --> B["Detect source and fingerprint case"]
B --> C["Inventory source pieces and build routing worklist"]
C --> D{"Piece-level handler"}
D --> D1["FHIR helper"]
D --> D2["OMOP helper"]
D --> D3["Generic helper"]
D --> D4["PDF text extraction"]
D --> D5["Run-local Python"]
D --> D6["Direct review"]
D1 --> E["Stage structured rows,<br/>documents, and visit candidates"]
D2 --> E
D3 --> E
D4 --> E
D5 --> E
D6 --> E
E --> F["Review timing, visit grouping,<br/>and unresolved evidence"]
F --> G["Package visit-centric harmonized timeline<br/>plus non-visit evidence"]
G --> H["Create question-specific analysis plan"]
H --> I{"Question type"}
I --> I1["Search mode:<br/>narrow time range, visit XML first,<br/>tables and code as needed"]
I --> I2["Summary mode:<br/>visit summaries, memory pass,<br/>longitudinal synthesis"]
I1 --> J["Reflection-driven validation"]
I2 --> J
J --> K["Deliver report, answer JSON,<br/>evidence table, and visit summaries"]Patient-scoped and question-scoped organization
The workflow separates patient-level artifacts from question-level artifacts. Each patient or source package is assigned a stable case folder keyed to the input path and source fingerprint. Shared artifacts include a manifest, a source inventory, a harmonized timeline, patient-level analysis logs, and staging files. New questions are answered in fresh question-specific workspaces containing analysis plans, validation logs, and final deliverables.
This separation is important because longitudinal QA is rarely one-shot. A user may ask for a patient summary, later ask about a particular admission, and then ask for a medication count across a lookback window. The workflow therefore treats harmonization as a reusable patient substrate and question answering as a downstream operation that can be repeated, audited, and compared across multiple requests.
Source detection and piece-level routing
The workflow begins with source detection, which classifies an input package globally as FHIR, OMOP, mixed, or unknown and records a source fingerprint for reuse decisions. Global detection is treated only as a draft recommendation. A second step builds a piece-level harmonization worklist that inventories individual source pieces and recommends a handler for each one: FHIR helper, OMOP helper, generic helper, PDF text extraction, run-local Python, or direct review.
This piece-level routing strategy addresses a common failure mode in EHR processing: all-or-nothing conversion. Mixed chart exports rarely behave as a single coherent format. Encounter tables may be structured and reliable, medication rows may require cross-file linkage, and note PDFs may contain clinically important evidence but weak metadata. By routing at the level of source pieces rather than whole cases, the workflow allows one patient package to combine schema-aware conversion with targeted fallback logic.
Staging as reviewable intermediate state
All helper paths write to a shared staging layer instead of directly producing a fully trusted final timeline. The staging layer includes structured rows normalized into standard categories such as conditions, procedures, labs, medications, clinical notes, radiology reports, and other events; a document inventory capturing note and PDF provenance plus timing clues; and visit candidates representing draft encounter hypotheses before final packaging.
This staging layer is deliberate. It creates an inspectable intermediate state in which automation can accelerate repetitive conversion while still exposing weak links. Helper-generated timestamps may come from structured fields, filenames, or filesystem metadata. Document-to-visit assignment may remain provisional. Some source pieces may fail to stage cleanly. Rather than hiding these uncertainties, the workflow records them as assumptions, unresolved items, and validation notes.
Visit-centric harmonized timeline
After staging, the workflow packages evidence into a harmonized timeline organized around visits plus a top-level non-visit bucket. Each visit contains two complementary evidence surfaces. The first is a set of standard tables, one per clinical category, preserving row-level structure and supporting deterministic queries. The second is a visit_timeline.xml file whose events carry a timestamp, event identifier, table name, row identifier, source reference, confidence, and short summary. At the patient level, a compact patient_timeline.json stores visit ordering, non-visit summaries, time bounds, and provenance counts without duplicating all row contents.
This design reflects how temporal QA is typically performed. Many questions are not about the entire record uniformly; they are about a bounded clinical episode, the relationship between episodes, or the sequence of events inside a single episode. The visit folder becomes the unit of temporal coherence, while the non-visit bucket acts as a safety valve for evidence that cannot yet be assigned confidently.
Agent-owned temporal adjudication
Several decisions remain explicitly review-owned: whether document content outweighs filesystem metadata, whether a note or PDF can be assigned a plausible encounter time, whether draft visits should be merged or split, whether evidence should remain outside visits, and whether a provisional timestamp is trustworthy enough for the current question.
This choice is not anti-automation; it is pro-accountability. EHR time is often clinically ambiguous. A discharge summary may mention earlier events. A PDF filename may reflect export date rather than care date. An ICU stay may be nested within a broader hospitalization. Fully automating these decisions risks false precision. By keeping them reviewable, the workflow turns temporal adjudication into part of reasoning rather than an invisible preprocessing side effect.
Question planning and routing
Before answering a question, the workflow writes an explicit analysis plan containing the question type, time range, visit selection strategy, candidate tables, whether table queries are needed, whether external lookup is required, whether code execution is required, and planned reflection checkpoints.
Two main question modes are supported. Search mode is used for earliest/latest questions, counts, threshold checks, targeted aggregation, and event lookup. The system infers the narrowest defensible time range, selects candidate visits from the patient timeline, reads visit XML first, and consults tables only when more detail or deterministic calculation is needed. Summary mode is used for patient-journey synthesis and longitudinal explanations. The system summarizes relevant visits from XML first and then integrates these summaries across time. For long or noisy records, the workflow adopts a Traj-CoA-inspired worker-memory-manager pattern in which visit-level summaries populate a shared memory before a manager pass produces the final narrative [11].
Deterministic code execution and validation
The workflow explicitly permits local Python for deterministic subtasks such as filtering tables, validating chronology, resolving medication names across files, checking lookback windows, and computing counts. This matters because some QA subtasks are better handled by code than by free-form reasoning. For example, identifying the last prescribed medication in an encounter may require ranking orders by timestamp and reconciling dosage-only rows with dispense evidence. Counting distinct medications in a chart-relative window requires explicit inclusion and exclusion logic.
After important retrieval or calculation steps, the workflow performs reflection-driven validation. The validation log records why a tool was needed, which claim it supported, whether it changed the answer, whether it altered inferred timing, whether contradictory evidence exists elsewhere, and whether the selected visit set remains appropriate. This log is central to the trust model: answers are accepted not merely because the pipeline completed, but because the reasoning and evidence checks converge.
Deliverables
Each answered question produces four required outputs: a narrative report, a structured answer JSON, an evidence table, and visit summaries. These outputs are tied to the shared patient timeline rather than replacing it. The report surfaces visit selection, timeline highlights, answer text, limitations, and validation notes. The structured answer captures confidence, cited visits, and sanity checks. The evidence table provides claim-level provenance. Together, these deliverables support both human review and downstream system integration.
Results
Package-grounded evaluation setup
This paper reports results from two bundled de-identified case bundles and three included question workflows. The goal is not to claim benchmark superiority, but to examine whether the workflow yields reusable patient representations and evidence-backed answers across heterogeneous longitudinal tasks without re-executing the skill for this manuscript.
The bundled artifacts contain chart-internal dates in years such as 2129 and 2155. We report those dates exactly as recorded because temporal reasoning in this setting must respect the chart's internal clock rather than substitute present-day calendar assumptions.
Case bundle 1 was a mixed-format export with 29 source files. The packaged timeline contained 5 draft visits, 241 non-visit events, and 5,263 staged structured rows. Its five visits contained 110, 174, 217, 4,438, and 83 events respectively. The largest visit spanned 2155-12-02T19:36:00-05:00 to 2155-12-07T15:30:00-05:00 and contained 3,968 laboratory events, 444 medication rows, 23 other events, and 3 procedures.
Case bundle 2 was a mixed-format export with 32 source files, including four PDF clinical notes. The packaged timeline contained 3 draft visits, 174 non-visit events, 3,176 staged structured rows, and 4 document inventory entries from the PDF layer. Its three packaged visits covered an emergency department episode, an ICU stay, and a broader hospitalization, with event counts of 66, 1, and 2,935 respectively. In both bundles, harmonization status remained provisional, meaning the artifacts preserved unresolved timing or assignment questions rather than fabricating certainty.
Case study 1: longitudinal hospitalization summary
The first question asked for a patient-level longitudinal summary over an acute hospitalization. The workflow selected all three packaged visits because the request was narrative and trajectory-oriented rather than encounter-specific. The evidence spanned an emergency department episode from 2129-04-05T21:18:00-04:00 to 2129-04-06T00:25:00-04:00, an ICU stay from 2129-04-06T00:25:00-04:00 to 2129-04-08T21:02:55-04:00, and a broader hospitalization from 2129-04-05T22:56:00-04:00 to 2129-04-11T17:25:00-04:00. These packaged units contained 66, 1, and 2,935 events respectively; the hospitalization-level visit alone contained 2,722 laboratory events, 144 medication rows, 67 other clinical events, and 2 procedures.
The resulting report synthesized the admission as a coherent temporal trajectory rather than as a flat extraction. Early emergency evidence recorded the chief complaint VOMITING BLOOD and laboratory abnormalities including sodium 128 mEq/L and leukocytosis 15.6 K/uL. During the hospitalization, microbiology named Escherichia coli, hemoglobin fell from 13.8 g/dL to 9.3 g/dL, platelet count fell to 104 K/uL, and arterial pO2 reached 59 mm Hg. Management evidence included pantoprazole infusion, dopamine infusion ordering, upper-GI procedure evidence, vancomycin, and levofloxacin. By 2129-04-11, hemoglobin had improved to 12.1 g/dL and sodium to 138 mEq/L, supporting a late-course recovery pattern prior to discharge.
This case shows three practical advantages of the workflow. First, the visit-centric structure made it possible to narrate emergency presentation, ICU transfer, and inpatient recovery as one temporally grounded story. Second, the workflow tolerated incompleteness without failing silently: diagnosis rows such as severe sepsis, acute respiratory failure, hyponatremia, aspiration-related pneumonitis, urinary tract infection, and ulcer-with-hemorrhage remained in staging rather than in final packaged condition tables, but they were still acknowledged as staged evidence. Third, four inventoried PDF notes were not used affirmatively because text extraction was unavailable. The final answer therefore remained evidence-backed while explicitly bounded by what the bundle could support.
Case study 2: encounter-bounded medication identification
The second question asked for the last drug prescribed during the first hospital encounter. This is a narrow search problem, but it is clinically realistic because it combines temporal bounding, encounter disambiguation, and cross-source medication resolution.
The workflow first established that the relevant encounter was not the earlier emergency department episode but the first hospital encounter in the structured encounter table: encounter 21322534, spanning 2155-05-08T17:05:00-04:00 to 2155-05-10T18:55:00-04:00. In the packaged timeline, this corresponded to a visit with 174 events: 103 laboratory rows, 70 medication rows, and 1 procedure. The latest medication order inside the encounter window occurred at 2155-05-10T12:25:57-04:00 and pointed to order 46111468. Because that row preserved dosage text (500 mg Tablet) rather than a reliable medication name, the workflow used deterministic Python to link the order identifier to dispense evidence and same-visit medication administration evidence. A later administration event at 2155-05-10T14:22:00-04:00 recorded LEV500, reinforcing the interpretation that levofloxacin was the last prescribed drug in that hospitalization.
This answer did not come from naive table lookup alone. It depended on temporal bounding, cross-file reconciliation, and explicit refusal to trust provisional packaging by itself when the question required stronger evidence. The same patient representation that supported broad summarization also supported precise encounter-bounded retrieval because the workflow preserved visit structure, provenance, and the option for deterministic follow-up logic.
Case study 3: chart-relative temporal aggregation
The third question asked for the number of distinct medicines prescribed since 13 months ago. The chart used future-dated timestamps relative to the present calendar, making the phrase "13 months ago" ambiguous if interpreted against wall-clock time. The workflow therefore normalized the phrase against the chart itself and recorded that assumption explicitly in the analysis plan and calculation output.
The latest chart timestamp in the packaged patient timeline was 2155-12-07T18:19:18-05:00, yielding a chart-relative lookback start of 2154-11-07T18:19:18-05:00. All five packaged visits fell within that window, so the question was treated as a whole-record medication aggregation rather than as a single-visit query. A deterministic script then processed medication orders inside the window and counted 40 distinct medicines from 119 included order rows while excluding 7 rows judged to be supply-like or service orders. Included examples comprised Heparin, Vancomycin, Amiodarone, Ferric Gluconate, Acetaminophen IV, Levofloxacin, and Warfarin. Excluded examples included repeated Floor Stock Bag rows and the non-medication service order IV therapy.
This case highlights two broader properties of the workflow. First, temporally ambiguous user language can be normalized against chart-internal time when that reasoning is made explicit. Second, evidence-backed QA over longitudinal EHRs often requires defensible exclusion logic, not only positive retrieval. The answer depended not merely on finding medication rows, but on deciding which rows should count as medicines and which should remain outside the semantic scope of the question.
Cross-case observations
Across the three examples, several practical patterns emerged. The reusable patient-level case folder reduced repeated setup cost: once a case bundle had been detected, fingerprinted, and packaged, additional questions could reuse the harmonized timeline while adding question-specific reasoning artifacts. The XML-first, table-second strategy worked well as a retrieval policy: visit XML files served as concise temporal maps, while tables were accessed only for calculations, exact values, or provenance recovery. The bundled cases also show why unresolved evidence matters operationally. One bundle retained 241 non-visit events and the other 174, meaning that large fractions of patient evidence would have been hidden or overcommitted if every artifact had been forced into a visit. In this setting, provisionality is not a defect but a safeguard against unsupported precision.
Discussion
Why temporal reasoning is the core value proposition
The main lesson from these case studies is that longitudinal EHR QA fails when time is treated as metadata instead of as clinical meaning. Questions about "first hospitalization," "last prescribed medication," "since 13 months ago," or "how the admission evolved" cannot be answered faithfully by flattening the chart into a bag of codes or by relying on schema conversion alone. They require a system that can decide which timestamps matter, which events belong together, and how uncertainty should be represented.
That is why temporal reasoning is the key contribution of this workflow. The method does not merely store timestamps; it operationalizes temporal judgment through visit construction, XML event sequencing, chart-relative windowing, provenance tracking, explicit staging of unresolved evidence, and reflection checkpoints. In effect, it creates a patient trajectory representation whose primary purpose is not compression but answerability.
Generalizability without over-normalization
A second lesson is that generalizability does not require collapsing everything into a single final ontology before reasoning begins. FHIR and OMOP are valuable inputs, and the workflow includes dedicated helpers for each. But many real chart packages are mixed, partial, or locally exported in ways that do not justify monolithic conversion. The piece-level routing and staging design allow the system to exploit standards where they help while still accommodating unsupported slices through targeted code or direct review.
This design is especially important for future deployment settings. Institutions differ in EHR configuration, export pathways, note availability, and cross-table link quality. A generalizable longitudinal QA workflow must therefore generalize at the operational level, not only at the representation level. The stable case folder, source fingerprinting, standard table contract, XML event schema, and question-specific analysis plan together provide that operational generalizability.
Implications for "Chat with EHR"
The broader application is an interactive "Chat with EHR" paradigm. A useful conversational EHR system cannot only summarize. It must answer precise temporal questions, explain which evidence supports the answer, show where uncertainty remains, and reuse prior harmonization work efficiently. The workflow described here contributes exactly those ingredients: a reusable patient substrate, grounded citations, explicit uncertainty, and a route for combining narrative reasoning with deterministic calculation.
In this framing, "Chat with EHR" should not mean unrestricted free-text generation over raw chart dumps. It should mean conversation over a structured, evidence-preserving temporal memory of the patient. The harmonized timeline becomes the memory layer; XML event summaries become the conversational retrieval surface; tables provide exactness when needed; and validation logs provide accountability. Recent retrieval-grounded and agentic systems have strengthened this direction [16,18], but the present results suggest that they will be most useful when coupled to a patient-level temporal representation rather than to undifferentiated chart text.
Limitations
This manuscript is based on the inspected package, bundled references, and included case artifacts rather than on prospective runtime benchmarking. The results therefore demonstrate workflow behavior and representational adequacy, not comparative accuracy against external baselines. The case studies also reveal open issues that should be treated as future work rather than hidden: some visit IDs remain provisional, note PDFs may resist extraction, non-visit buckets may contain clinically important evidence awaiting assignment, and helper packaging may omit staged rows that later matter for interpretation.
These limitations are informative. They show that clinical QA systems should expose unresolved temporal structure rather than papering over it. Future work should evaluate the workflow on larger multi-format cohorts, quantify the effect of review on temporal correctness, measure answerability before and after harmonization review, and compare different memory and summarization strategies for long trajectories.
Conclusion
Longitudinal EHR question answering is fundamentally a temporal reasoning problem. A trustworthy system must preserve provenance, support heterogeneous inputs, allow deterministic audit where appropriate, and avoid false certainty when the record is ambiguous. The workflow described here addresses these needs through reusable patient-level harmonization, visit-centric packaging, explicit temporal adjudication, question-specific planning, and reflection-driven validation. The bundled case studies show that this design supports both broad trajectory summarization and narrowly scoped evidence retrieval. More importantly, they suggest a path toward generalizable and valuable patient-level QA systems in which "Chat with EHR" is grounded not in generic text generation, but in evidence-based temporal reasoning over the patient trajectory.
References
- Choi E, Bahadori MT, Schuetz A, Stewart WF, Sun J. Doctor AI: Predicting Clinical Events via Recurrent Neural Networks. JMLR Workshop and Conference Proceedings. 2016;56:301-318. Available from: https://pubmed.ncbi.nlm.nih.gov/28286600/
- Choi E, Bahadori MT, Kulas JA, Schuetz A, Stewart WF, Sun J. RETAIN: An Interpretable Predictive Model for Healthcare using Reverse Time Attention Mechanism. Advances in Neural Information Processing Systems. 2016. Available from: https://papers.neurips.cc/paper/6321-retain-an-interpretable-predictive-model-for-healthcare-using-reverse-time-attention-mechanism
- Li Y, Rao S, Solares JRA, et al. BEHRT: Transformer for Electronic Health Records. Scientific Reports. 2020;10:7155. Available from: https://www.nature.com/articles/s41598-020-62922-y
- Rasmy L, Xiang Y, Xie Z, Tao C, Zhi D. Med-BERT: pretrained contextualized embeddings on large-scale structured electronic health records for disease prediction. npj Digital Medicine. 2021;4:86. Available from: https://pubmed.ncbi.nlm.nih.gov/34017034/
- Hripcsak G, Duke JD, Shah NH, et al. Observational Health Data Sciences and Informatics (OHDSI): Opportunities for Observational Researchers. Studies in Health Technology and Informatics. 2015;216:574-578. Available from: https://pubmed.ncbi.nlm.nih.gov/26262116/
- Mandel JC, Kreda DA, Mandl KD, Kohane IS, Ramoni RB. SMART on FHIR: a standards-based, interoperable apps platform for electronic health records. Journal of the American Medical Informatics Association. 2016;23(5):899-908. Available from: https://pubmed.ncbi.nlm.nih.gov/26911829/
- Rajkomar A, Oren E, Chen K, et al. Scalable and accurate deep learning with electronic health records. npj Digital Medicine. 2018;1:18. Available from: https://www.nature.com/articles/s41746-018-0029-1
- Sun W, Rumshisky A, Uzuner O. Evaluating temporal relations in clinical text: 2012 i2b2 Challenge. Journal of the American Medical Informatics Association. 2013;20(5):806-813. Available from: https://pubmed.ncbi.nlm.nih.gov/23564629/
- Bethard S, Savova G, Chen WT, Derczynski L, Pustejovsky J, Verhagen M. SemEval-2016 Task 12: Clinical TempEval. In: Proceedings of the 10th International Workshop on Semantic Evaluation. 2016. Available from: https://aclanthology.org/S16-1165/
- Pampari A, Raghavan P, Liang J, Peng J. emrQA: A Large Corpus for Question Answering on Electronic Medical Records. In: Proceedings of the 2018 Conference on Empirical Methods in Natural Language Processing. 2018. Available from: https://aclanthology.org/D18-1258/
- Zeng S, Fu Y, Zhou S, Yu Z, Liu LJ, Wen J, Thompson M, Etzioni R, Yetisgen M. Traj-CoA: Patient Trajectory Modeling via Chain-of-Agents for Lung Cancer Risk Prediction. GenAI4Health Workshop / OpenReview preprint. 2025. Available from: https://openreview.net/forum?id=S4GfRvVTHV
- Pellegrini C, Ozsoy E, Bani-Harouni D, Keicher M, Navab N. EHR2Path: Scalable Modeling of Longitudinal Health Trajectories with LLMs. ICLR 2026 submission / OpenReview preprint. 2025-2026. Available from: https://openreview.net/forum?id=SEkfuZtf75
- Huang L, Chaturvedi R, Di Eugenio B, Boyd A, Layden BT, Cheng L. HeLoM: Progressive Disease Detection with Heterogeneous and Longitudinal EHRs via Memory-Augmented LLMs. ICLR 2026 withdrawn submission / OpenReview preprint. 2025-2026. Available from: https://openreview.net/pdf?id=VBMdD2owBe
- Bardhan J, Roberts K, Wang DZ. Question Answering for Electronic Health Records: Scoping Review of Datasets and Models. Journal of Medical Internet Research. 2024;26:e53636. Available from: https://www.jmir.org/2024/1/e53636
- Shi W, Xu R, Zhuang Y, Yu Y, Zhang J, Wu H, Zhu Y, Ho J, Yang C, Wang MD. EHRAgent: Code Empowers Large Language Models for Few-shot Complex Tabular Reasoning on Electronic Health Records. In: Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing. 2024. Available from: https://pubmed.ncbi.nlm.nih.gov/40018366/
- Low YS, Jackson ML, Hyde RJ, Brown RE, Sanghavi NM, Baldwin JD, et al. Answering real-world clinical questions using large language model, retrieval-augmented generation, and agentic systems. Digital Health. 2025;11:20552076251348850. Available from: https://pubmed.ncbi.nlm.nih.gov/40510193/
- Singhal K, Tu T, Gottweis J, et al. Toward expert-level medical question answering with large language models. Nature Medicine. 2025;31(3):943-950. Available from: https://pubmed.ncbi.nlm.nih.gov/39779926/
- Amugongo LM, Mascheroni P, Brooks S, Doering S, Seidel J. Retrieval augmented generation for large language models in healthcare: A systematic review. PLOS Digital Health. 2025;4(6):e0000877. Available from: https://pubmed.ncbi.nlm.nih.gov/40498738/
Reproducibility: Skill File
Use this skill file to reproduce the research with an AI agent.
---
name: longitudinal-ehr-qa
description: Answer patient-level longitudinal EHR questions by building or reusing a harmonized hierarchical timeline instead of forcing every source into a FHIR-first reasoning flow. Use when Codex receives local patient data that may be FHIR, OMOP, mixed CSV/JSON/XML/text/PDF files, or a partially structured chart export, and the user wants an evidence-backed answer, timeline summary, or temporal search over visits with optional web or PubMed grounding, tool use, code execution, and reflection-driven validation.
---
# Longitudinal EHR QA
Use this skill to answer questions about one patient's record with a reusable visit-centric timeline package and per-question workspaces.
## Core model
Treat the harmonized timeline as an agent-reviewed reasoning surface, not a fully trusted preprocessing product.
- Do not harmonize every source into generic FHIR for final reasoning.
- Keep FHIR as a supported source format and converter input.
- Group the record into visit folders plus a top-level `non_visit_events/` bucket.
- Inside each visit, keep both:
- standard tables such as `conditions`, `procedures`, `labs`, `medications`, `clinical_notes`, and `radiology_reports`
- a `visit_timeline.xml` file with timestamped, agent-friendly events that point back to table rows and source artifacts
- Reuse the saved harmonized timeline when it already exists and the source fingerprint still matches.
- Let scripts gather evidence and draft structure, but keep ambiguous timing, visit grouping, and evidence interpretation under agent control.
- Treat file modified times, PDF metadata, filename dates, and heuristic grouping as weak clues until the agent accepts them.
## Agent-Owned Decisions
Own these decisions yourself instead of outsourcing them to helper scripts:
- infer PDF visit time from the document content when the content is informative
- decide when document content is stronger than filesystem or filename metadata
- decide whether an ambiguous document belongs to an existing visit, a split visit, a merged visit, or `non_visit_events/`
- decide whether a provisional timestamp should be accepted, revised, or left unresolved
- decide whether extra code, web search, or PubMed lookup is actually needed
- decide when writing Python yourself is the best way to make a step deterministic and auditable
## Stable patient folder
Write all patient-shared artifacts for one patient or source package under one stable folder:
```text
./runs/longitudinal-ehr-qa/<case-key>/
```
Keep this structure stable:
```text
manifest.json
source_inventory.json
harmonized_timeline/
analysis/
staging/
questions/
<question-key>/
analysis/
outputs/
```
Treat `manifest.json`, `source_inventory.json`, `harmonized_timeline/`, the root `analysis/`, and `staging/` as patient-level shared artifacts. Reuse them across multiple questions for the same patient when the source fingerprint still matches.
For each new user question, create a fresh question workspace under `questions/<question-key>/`. Put question-specific planning, validation, ad hoc calculations, and final answer bundle there. Do not overwrite a previous question workspace just because it targets the same patient.
The harmonized timeline contract is defined in [references/harmonized-timeline-contract.md](./references/harmonized-timeline-contract.md).
Format detection and converter strategy live in [references/source-format-and-converters.md](./references/source-format-and-converters.md).
## Installation And Path Resolution
Do not assume a single skills root.
- Codex-style installs may use `${CODEX_HOME:-$HOME/.codex}/skills/longitudinal-ehr-qa`
- Claude-style installs may use `${CLAUDE_HOME:-$HOME/.claude}/skills/longitudinal-ehr-qa`
- other local setups may use another shared skills directory
When running bundled scripts, resolve the actual installed skill path first and use that resolved path as `SKILL_DIR`.
## Workflow
### Workflow diagram
Use this diagram as the operational map for the skill. It shows where bundled scripts accelerate only part of the work, where the agent must make the final routing and temporal decisions, and how staged evidence becomes the final harmonized timeline.
```mermaid
flowchart TD
A["User asks a patient-level longitudinal question<br/>with local chart artifacts"] --> B["Resolve SKILL_DIR and input path<br/>Create or locate stable patient folder"]
B --> C["Run detect_source.py<br/>Write source_inventory.json, manifest.json, case_key"]
C --> C1["Run build_harmonization_worklist.py<br/>Write harmonization_plan.json,<br/>harmonization_journal.jsonl, source_piece_inventory.jsonl"]
C1 --> D{"Existing harmonized timeline<br/>and matching fingerprint?"}
D -->|Yes| E["Reuse patient-shared artifacts<br/>Do not reconvert automatically"]
D -->|No| F["Agent reviews source pieces and chooses one handler per piece"]
subgraph Routing["Piece-level routing"]
F --> G["Use fhir-helper for clean FHIR slices"]
F --> H["Use omop-helper for clean OMOP slices"]
F --> I["Use generic-helper for mixed local exports"]
F --> J["Use pdf-text-extract for PDF readability and provenance"]
F --> K["Write run-local Python for unsupported slices"]
F --> L["Handle a piece manually when helper output is insufficient"]
end
G --> M["Stage normalized rows, document metadata,<br/>and visit candidates under staging/"]
H --> M
I --> M
J --> M
K --> M
L --> M
E --> M
subgraph Timeline["Harmonization and timeline finalization"]
M --> N["Agent reviews staged evidence,<br/>notes, PDFs, helper output, and unresolved slices"]
N --> O["Decide trusted timestamps,<br/>split or merge visits, keep unresolved events,<br/>and revise candidate visit assignment"]
O --> P["Package reviewed staging with package_staged_timeline.py<br/>or equivalent agent-authored packaging step"]
P --> Q["Append review notes to<br/>analysis/validation_log.jsonl and harmonization_journal.jsonl"]
end
Q --> Q1["Create or locate<br/>questions/<question-key>/ workspace"]
Q1 --> R["Write questions/<question-key>/analysis/analysis_plan.json<br/>before deep reasoning"]
R --> S{"Question type?"}
subgraph Reasoning["Question routing and evidence gathering"]
S -->|Search| T["Infer narrow time range<br/>Select candidate visits<br/>Read visit_timeline.xml first"]
S -->|Summary| U["Summarize relevant visits from XML first<br/>Then synthesize longitudinally across visits"]
T --> V["Use tables only when needed for detail or calculation"]
U --> V
V --> W{"Need stronger evidence?"}
W -->|Deterministic checks| X["Write or run Python / query_visit_table.py<br/>for counts, joins, filters, thresholds"]
W -->|External grounding| Y["Use web or PubMed only when chart evidence is insufficient"]
W -->|No| Z["Synthesize answer from chart evidence"]
X --> Z
Y --> Z
end
Z --> AA["Reflect after each critical step:<br/>check unsupported claims, timestamp weakness,<br/>visit assignment errors, evidence conflicts"]
AA --> AB{"Issue found?"}
AB -->|Yes| AC["Revise visit routing, staged evidence,<br/>harmonization decisions, or calculations"]
AC --> T
AB -->|No| AD["Create final deliverables"]
subgraph Deliverables["Completion gate before answering"]
AD --> AD1["questions/<question-key>/outputs/final_report.md"]
AD --> AD2["questions/<question-key>/outputs/final_answer.json"]
AD --> AD3["questions/<question-key>/outputs/evidence_table.csv"]
AD --> AD4["questions/<question-key>/outputs/visit_summaries.jsonl"]
AD --> AD5["harmonized_timeline/patient_timeline.html"]
AD --> AD6["harmonized_timeline/patient_timeline.json"]
end
AD1 --> AE["Return an evidence-backed answer<br/>or say the record is insufficient"]
AD2 --> AE
AD3 --> AE
AD4 --> AE
AD5 --> AE
AD6 --> AE
```
Read the diagram from left to right as four layers:
- intake and patient-level setup
- harmonization and agent-owned timeline review
- question workspace setup, routing, tool use, and reflection-driven validation
- required deliverables that gate completion
Treat the diagram as a contract, not decoration: helper scripts are optional accelerators for selected slices of the record, not a rigid whole-case pipeline.
### 1. Detect the source and create or reuse the patient folder
Use `uv` for bundled Python scripts.
Resolve the skill directory dynamically. Do not assume this skill lives under a fixed root such as `skills/`, `.codex/`, or `.claude/`.
```bash
SKILL_DIR="<absolute-path-to-this-skill-folder>"
INPUT_PATH="<input-path>"
uv run --project "$SKILL_DIR" python "$SKILL_DIR/scripts/detect_source.py" \
"$INPUT_PATH" \
--output-root ./runs/longitudinal-ehr-qa
```
If the skill was invoked with an explicit path, use that path directly. Otherwise discover it from the local skills root before running scripts.
This writes or refreshes the shared patient artifacts:
- `source_inventory.json`
- `manifest.json` fields related to source fingerprint and detected format
- the stable patient folder key in `case_key`
If the patient folder already contains a standard harmonized timeline and the fingerprint matches, reuse it. Do not reconvert.
Do not assume reused artifacts are final. Reused artifacts may still require harmonization review.
### 2. Build a piece-level harmonization worklist
Before choosing any helper, build a per-piece routing plan:
```bash
uv run --project "$SKILL_DIR" python "$SKILL_DIR/scripts/build_harmonization_worklist.py" \
"$INPUT_PATH" \
--output-root ./runs/longitudinal-ehr-qa
```
This writes:
- `analysis/harmonization_plan.json`
- `analysis/harmonization_journal.jsonl`
- `staging/source_piece_inventory.jsonl`
- empty staging files for normalized rows, documents, and visit candidates
Treat `source_piece_inventory.jsonl` as the default routing surface. A piece may be a file, resource stream, table, note, PDF, or other document-like artifact.
For each piece, choose one handler:
- `fhir-helper`
- `omop-helper`
- `generic-helper`
- `pdf-text-extract`
- `run-local-python`
- `agent-manual`
Do not require one converter for the whole case. It is normal for one patient record to use several handlers in the same harmonization run.
### 3. Stage evidence with helpers, ad hoc Python, or agent review
Use bundled converters as optional accelerators:
- `scripts/convert_fhir_to_timeline.py` for clean FHIR slices
- `scripts/convert_omop_to_timeline.py` for clean OMOP slices
- `scripts/package_generic_timeline.py` for mixed local exports
- `scripts/extract_pdf_text.py` for readable PDF text and provenance only
When a helper is insufficient:
- write run-local Python inside the patient folder or active question workspace
- stage normalized rows into `staging/structured_tables.jsonl`
- stage note or PDF provenance into `staging/document_inventory.jsonl`
- stage visit hypotheses into `staging/visit_candidates.jsonl`
- record routing, fallbacks, unresolved ambiguity, and manual overrides in `analysis/harmonization_journal.jsonl`
When the source is FHIR and mapping details matter, use the bundled upstream reference at [vendor/fhir-developer-skill/SKILL.md](./vendor/fhir-developer-skill/SKILL.md). Treat it as a format-specific helper guide, not the main reasoning flow.
### 4. Review and finalize the harmonization yourself
Before writing the question-specific `analysis_plan.json`, inspect staged evidence and decide:
- which visit times are trustworthy
- which timestamps remain provisional
- whether any draft visits should be split, merged, or dropped
- whether any PDFs or text notes change visit timing
- whether some evidence should remain outside visits
- which source pieces were never staged successfully and why
Package reviewed staging into the standard timeline with `scripts/package_staged_timeline.py` or an equivalent agent-authored packaging step. Only after this review should final time-bearing `visit_id`s be treated as canonical for reasoning.
Record this review in both `analysis/validation_log.jsonl` and `analysis/harmonization_journal.jsonl`.
### 5. Create a question workspace and write `analysis_plan.json` before reasoning
Before deep reasoning, create or reuse a question-specific folder:
```text
questions/<question-key>/
analysis/
outputs/
```
Use a stable slug for `<question-key>`. Preserve prior question folders for the same patient instead of overwriting them.
Write the reasoning plan to:
```text
questions/<question-key>/analysis/analysis_plan.json
```
Always write an explicit plan before answering. Use this minimum shape:
```json
{
"question": "original user question",
"question_type": "search | summary",
"time_range": {
"start": "optional ISO datetime",
"end": "optional ISO datetime",
"rationale": "why this scope is enough"
},
"visit_selection_strategy": "how candidate visits were chosen",
"table_candidates": ["labs", "clinical_notes"],
"needs_table_queries": true,
"needs_web_lookup": false,
"needs_pubmed_lookup": false,
"needs_code_execution": true,
"reflection_checkpoints": [
"after visit selection",
"before final synthesis"
]
}
```
Do not start deep reasoning before this artifact exists.
### 6. Route the question explicitly
Read [references/temporal-reasoning-playbook.md](./references/temporal-reasoning-playbook.md) for the full reasoning loop.
Read [references/traj-coa-procedure.md](./references/traj-coa-procedure.md) when the question requires deep longitudinal synthesis across many visits, long records, or widely separated events.
For `search` questions:
- infer the narrowest defensible time range
- select visits from `patient_timeline.json`
- inspect the selected `visit_timeline.xml` files first
- query visit tables only when detailed extraction or calculation is needed
- aggregate over visits and include `non_visit_events/` when relevant
For `summary` questions:
- summarize each relevant visit from XML first
- treat `visit_timeline.xml` and `non_visit_timeline.xml` as the primary reasoning surface for summary tasks
- do not exhaustively query visit tables during summary mode unless a specific claim, calculation, or missing citation cannot be resolved from XML
- write structured visit summaries
- use a Traj-CoA-style worker-memory-manager pattern over the ordered visit summaries
- allow the agent to revise visit timing or visit assignment if XML, notes, or reports show the provisional harmonization was too coarse
### 6. Use tools only when they add evidence
Read [references/tooling-and-code-execution.md](./references/tooling-and-code-execution.md).
Rules:
- Write Python whenever you want a deterministic, inspectable step for counting, joins, filtering, trend checks, threshold logic, artifact extraction, or validation.
- Use `scripts/query_visit_table.py` for simple row filters or exact-value lookups.
- Use built-in web or PubMed search when chart evidence is insufficient for external factual grounding.
- Use ToolUniverse only as an optional accelerator when available. Do not make it a hard dependency for core EHR QA.
- For unknown source formats, inspect the patient folder, write run-local Python under the active question workspace or another clearly scoped subfolder, execute it with `uv run`, and promote only reusable logic back into the skill scripts.
- When timestamps are ambiguous, use scripts only to expose content and provenance. Make the timing decision yourself from chart content, provenance, and temporal consistency across visits.
- Prefer short Python checks when they make a claim easier to verify or reproduce. Do not hesitate to write code for deterministic subtasks even when the overall reasoning remains agent-led.
### 7. Reflect and validate after every critical step
Append question-level validation notes to:
```text
questions/<question-key>/analysis/validation_log.jsonl
```
Keep harmonization review notes in the shared patient-level files:
```text
analysis/validation_log.jsonl
analysis/harmonization_journal.jsonl
```
Run reflection after:
- source detection
- provisional harmonization or reuse
- harmonization review and finalization
- visit selection
- table-query calculations
- external lookups
- final synthesis
Check for:
- unsupported claims
- missing timestamps
- weak timestamps that came only from file metadata
- table-to-XML linkage errors
- visit assignment mistakes
- evidence conflicts
- reasons the time range should be widened
- reasons content evidence should override filesystem or filename metadata
- reasons a provisional visit should remain provisional
If the answer is still uncertain, say so directly.
### 8. Finish with evidence-based outputs
Read [references/report-contract.md](./references/report-contract.md) before drafting final deliverables.
Important: the converter and harmonization scripts do not automatically create the final report bundle. After reasoning is complete, the agent must author these files explicitly before returning the answer to the user.
Always write these files under the active question workspace:
- `questions/<question-key>/outputs/final_report.md`
- `questions/<question-key>/outputs/final_answer.json`
- `questions/<question-key>/outputs/evidence_table.csv`
- `questions/<question-key>/outputs/visit_summaries.jsonl`
Treat these files as a completion gate for every answered question. Do not stop after producing only intermediate artifacts such as `analysis_plan.json`, `validation_log.jsonl`, ad hoc calculation files, or a chat response. Before finishing, verify that all four output files exist under the active question workspace and create any missing ones.
The visual timeline should be:
- `harmonized_timeline/patient_timeline.html`
The machine-readable contract should be:
- `harmonized_timeline/patient_timeline.json`
If the answer is not found, say no, cite the nearest relevant evidence, and explain why the record is insufficient.
## Guardrails
- Do not silently reconvert a matching harmonized timeline.
- Do not hide ambiguous mappings.
- Do not answer from intuition when XML or table evidence does not support the claim.
- Do not treat helper output as authoritative when chart content tells a different temporal story.
- Do not require one converter or helper to process the entire patient record.
- Do not emit final time-bearing `visit_id`s before agent review is complete.
- Do not collapse orphan events into synthetic visits unless the source explicitly supports that grouping.
- Do not require ToolUniverse, PubMed, or web access for questions that can be answered from the chart alone.
- Do not let a low-quality timestamp source such as filesystem modification time override stronger evidence from document content.
## Bundled scripts
- `scripts/detect_source.py`: inspect the source package, write `source_inventory.json`, and recommend a draft converter path
- `scripts/build_harmonization_worklist.py`: inventory source pieces, recommend per-piece handlers, and initialize staging artifacts
- `scripts/convert_fhir_to_timeline.py`: use the FHIR helper fast path and stage helper output for later agent review
- `scripts/convert_omop_to_timeline.py`: use the OMOP helper fast path and stage helper output for later agent review
- `scripts/package_generic_timeline.py`: use the generic helper fast path and stage helper output for later agent review
- `scripts/extract_pdf_text.py`: extract PDF text and preserve provenance for later agent review
- `scripts/package_staged_timeline.py`: package reviewed staging artifacts into the stable final harmonized timeline outputs
- `scripts/render_timeline_html.py`: render `patient_timeline.html`
- `scripts/query_visit_table.py`: query one visit table for exact matches or substring filters
## References
- [references/harmonized-timeline-contract.md](./references/harmonized-timeline-contract.md)
- [references/source-format-and-converters.md](./references/source-format-and-converters.md)
- [references/temporal-reasoning-playbook.md](./references/temporal-reasoning-playbook.md)
- [references/traj-coa-procedure.md](./references/traj-coa-procedure.md)
- [references/tooling-and-code-execution.md](./references/tooling-and-code-execution.md)
- [references/report-contract.md](./references/report-contract.md)
- [vendor/fhir-developer-skill/SKILL.md](./vendor/fhir-developer-skill/SKILL.md)
Discussion (0)
to join the discussion.
No comments yet. Be the first to discuss this paper.