Skip to main content
Version: v0.0.3

Function: extractPlannedItems()

extractPlannedItems(sectionEl, narrativeById, ctx): readonly PlannedItem[]

Extract every planned item from a <section> element: each <entry> whose act carries one of the seven templates in PLANNED_VARIANTS, and each of the seven nested inside a Planned Intervention Act (PLANNED_INTERVENTION_ACT, …22.4.146). Never throws.

The container is named rather than inferred, and it is the only one. R2.1 gives the Planned Intervention Act an entryRelationship for every one of the seven, each holding the planned act inline, so before this a planned entry sitting there was returned as nothing with nothing said, for all seven kinds. A Planned Intervention Act nested in a Planned Intervention Act is descended into too, because the walk is the same walk; the DOM is a tree, so it terminates.

It is the only container descended into, and R2.1 has others, so this does NOT solve nesting in general. A Nutrition Recommendation (…22.4.130) inline-holds six of the seven by the identical entryRelationship pattern (every planned template except …22.4.120), and an Intervention Act (…22.4.131, the performed sibling and the SHOULD entry of an Interventions Section) inline-holds a Planned Intervention Act. A planned entry in either is still returned as nothing with nothing said. That is left as it was found: the scope taken here is the one container, and widening it is a decision with its own base-measured matrix, not a tidy-up. A test pins both as unreached so the bound is measured rather than asserted.

An entryRelationship is read for what it CONTAINS, never followed for what it REFERENCES. The template's [1..*] typeCode="RSON" relationship holds an Entry Reference (…22.4.122) whose own SHALL points at a Goal Observation. That act carries no planned template root, so it is walked past rather than resolved: its target lives elsewhere in the document and is reached on its own terms, and resolving a pointer here would return an item the container does not hold.

Which acts a Planned Intervention Act holds and this still does not return: the performed ones (MedicationActivity, ImmunizationActivity, ProcedureActivityProcedure, EncounterActivity, and the rest, none of which is planned and none of which carries a planned root), and the same three non-item templates the section itself admits (Instruction …22.4.20, Handoff Communication Participants …22.4.141, Nutrition Recommendation …22.4.130). Whether those three should be reported as dropped is an open decision, at both levels, and it is still recorded rather than taken.

A returned item does not say whether it was a direct <entry> or nested. The Planned Intervention Act is not modelled: this package carries no container type, no goal linkage, and no nested flag, so the grouping toward a goal is available only from doc.toString(). What getPlannedItems() answers is which acts are planned for this patient, and a nested one is planned on exactly the same terms as a direct one. Each item keeps its own ids, so a caller that needs the grouping can correlate.

Parameters

sectionEl

Element

narrativeById

ReadonlyMap<string, string>

ctx

ParseCtx

Returns

readonly PlannedItem[]

Example

import { extractPlannedItems } from "@cosyte/ccda";
const planned = extractPlannedItems(sectionEl, section.narrativeById, ctx);