slug: elation-health provider: Elation Health generated_by: planning/capability-mapping/scripts/classify_capabilities.py model: claude-opus-5 frame: - Healthcare Providers min_confidence: 0.7 capability_model: source: https://github.com/vincentmakes/turbo-ea-capabilities license: CC-BY-4.0 attribution: Turbo EA Capabilities by Vincent Verdet — Turbo EA, https://github.com/vincentmakes/turbo-ea-capabilities, CC BY 4.0 notice: NOTICE edge_count: 51 edges: - tag: Visit Notes spec_file: elation-health-visit-notes-api-openapi.yml capability_id: BC-2830.10 capability_id_l1: BC-2830 capability_name: Clinical Note Documentation confidence: 0.95 evidence: PATCH /visit_notes/{id}/ sign-visit-note 'Sign Visit Note'; schemas VisitNote, AddSignaturesToNote, AmendmentRequest reason: Creation, amendment and signing of clinician visit notes is unambiguously clinical note documentation in the active patient record. - tag: Appointments spec_file: elation-health-appointments-api-openapi.yml capability_id: BC-2800.10 capability_id_l1: BC-2800 capability_name: Scheduling & Appointment Management confidence: 0.92 evidence: POST /appointments/ 'Create Event'; 'Update Appointment Slot'; schemas 'Appointment', 'AppointmentStatus', 'PaginatedAppointmentList' reason: Full lifecycle of patient appointments and slots in an EHR scheduling API — create, find, update, delete events and slots. This plainly performs appointment booking and slot management for a healthcare provider. - tag: Insurance Eligibility spec_file: elation-health-insurance-eligibility-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.92 evidence: GET /api/2.0/patient_insurances/{id}/eligibility/ 'Get Eligibility'; schemas EligibilityBenefits, EligibilityPlanDetails, InsuranceEligibilityFullReport reason: Operations run and retrieve payer eligibility checks with benefits and plan detail for a patient's insurance — textbook eligibility and benefits verification. - tag: Patient Insurances spec_file: elation-health-patient-insurances-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.92 evidence: GET /patient_insurances/{id}/eligibility/ 'Get Eligibility'; POST 'Create Eligibility'; GET '/eligibility_full_report/' reason: Operations run and retrieve insurance eligibility checks against a patient's coverage, which is precisely eligibility and benefits verification within patient access. - tag: Notes spec_file: elation-health-notes-api-openapi.yml capability_id: BC-2830.10 capability_id_l1: BC-2830 capability_name: Clinical Note Documentation confidence: 0.9 evidence: '''This API supports the management of visit notes.''; schemas VitalBP, Procedure-Output, DocumentSignature, ImmunizationVaccine' reason: Create/update/sign structured visit notes containing vitals, procedures and narrative sections — clinical note documentation. - tag: Notes v2 spec_file: elation-health-notes-v2-api-openapi.yml capability_id: BC-2830.10 capability_id_l1: BC-2830 capability_name: Clinical Note Documentation confidence: 0.9 evidence: POST /v2/notes/{note_id}/amendments create_note_amendment_v2; schemas ElationNoteAmendmentUpdate, VitalBP, ReferralBlock-Output reason: Visit note authoring plus amendment and doctag management — clinical note documentation in the EHR. - tag: Notes v1 spec_file: elation-health-notes-v1-api-openapi.yml capability_id: BC-2830.10 capability_id_l1: BC-2830 capability_name: Clinical Note Documentation confidence: 0.88 evidence: POST /v1/notes create_note_v1 Create Note V1; schemas NoteCreate, NoteUpdate, DocumentSignature reason: Versioned endpoint set for authoring visit notes with signatures — clinical note documentation. - tag: Referral Orders spec_file: elation-health-referral-orders-api-openapi.yml capability_id: BC-2820.10 capability_id_l1: BC-2820 capability_name: Referral Management confidence: 0.88 evidence: '"Post Referral Order", "Update Referral Order", "Get Referral Order"' reason: CRUD over referral orders is the capture and management of patient referrals to other providers — referral management within care coordination. - tag: Referrals spec_file: elation-health-referrals-api-openapi.yml capability_id: BC-2820.10 capability_id_l1: BC-2820 capability_name: Referral Management confidence: 0.88 evidence: '"List Referral Orders", "Create Referral Order"; schemas "ReferralOrder", "ReferralLetter", "MedicalSpecialty", "SendToContact"' reason: Operations create/track referral orders and referral letters with specialty and send-to-contact data — end-to-end referral management from order capture to specialist routing. - tag: Bills spec_file: elation-health-bills-api-openapi.yml capability_id: BC-2870 capability_id_l1: BC-2870 capability_name: Healthcare Revenue Cycle Management confidence: 0.85 evidence: POST /bills/ 'Create Bill'; PATCH /bills/{id}/actions/release-to-pms/ 'Release a Bill To PMS'; schemas 'CPT', 'DX', 'BillingStatusEnum', 'Payment' reason: Bills carrying CPT and diagnosis codes are created from encounters and released to the practice management system — provider-side charge capture feeding claim production. L1 healthcare revenue cycle is clear; the surface spans charge capture and downstream claim handoff, so no single L2 is asserted. - tag: Non Visit Notes spec_file: elation-health-non-visit-notes-api-openapi.yml capability_id: BC-2830.10 capability_id_l1: BC-2830 capability_name: Clinical Note Documentation confidence: 0.85 evidence: POST /non_visit_notes/ create-non-visit-note Create Non-Visit Note; schemas NonVisitNote, NonVisitNoteBullet, NonVisitNoteDocument reason: Authoring and lifecycle of clinician non-visit notes in the patient record — clinical note documentation. - tag: App spec_file: elation-health-app-api-openapi.yml capability_id: BC-4270.80 capability_id_l1: BC-4270 capability_name: Webhook & Event Subscription Management confidence: 0.82 evidence: POST /app/subscriptions/ 'Subscribe to a resource updates'; GET /app/published_events/ 'Find published events' reason: 'This tag is pure platform plumbing for API consumers: managing event subscriptions and published events for the vendor''s public API. That maps to outbound webhook/event subscription lifecycle in the developer-platform capability, not to any healthcare delivery capability.' - tag: Lab Order Sets spec_file: elation-health-lab-order-sets-api-openapi.yml capability_id: BC-2830.20 capability_id_l1: BC-2830 capability_name: Computerised Provider Order Entry confidence: 0.82 evidence: '''Create Lab Order Set'' / schemas LabOrderSet, LabOrderContent, LabOrderTestWithDiagnoses, ICD10Code' reason: Order sets for laboratory ordering are explicitly named in Computerised Provider Order Entry ('order sets and clinical protocols'); operations manage the lifecycle of these diagnostic order sets. - tag: Appointment Types spec_file: elation-health-appointment-types-api-openapi.yml capability_id: BC-2800.10 capability_id_l1: BC-2800 capability_name: Scheduling & Appointment Management confidence: 0.8 evidence: POST /api/2.0/appointment_types/ 'Create Appointment Type'; schema 'AppointmentType', 'VisitNoteFormatEnum' reason: CRUD over appointment types published in the vendor's scheduling API definition; these configure the bookable visit types used for appointment booking, so it realises scheduling & appointment management. It is configuration rather than booking itself, hence 0.8. - tag: Billing Codes spec_file: elation-health-billing-codes-api-openapi.yml capability_id: BC-2870 capability_id_l1: BC-2870 capability_name: Healthcare Revenue Cycle Management confidence: 0.8 evidence: POST /api/2.0/billing_codes/ 'Create Billing Code'; schemas 'CPTCode', 'PaginatedCPTCodeList' reason: Maintenance of CPT billing codes for a provider practice, published in the vendor's billing API. This is provider revenue-cycle code/charge master data; the split between chargemaster management and coding management is not resolvable from the evidence, so L2 is null. - tag: Event Subscriptions spec_file: elation-health-event-subscriptions-api-openapi.yml capability_id: BC-4270.80 capability_id_l1: BC-4270 capability_name: Webhook & Event Subscription Management confidence: 0.8 evidence: POST /api/2.0/app/subscriptions/ "Subscribe to a resource updates"; schemas PublishedEvent, Subscription reason: Purely platform plumbing for outbound event/webhook subscriptions exposed to API consumers — developer platform event subscription management, not a clinical capability. - tag: Outstanding Balance spec_file: elation-health-outstanding-balance-api-openapi.yml capability_id: BC-2870.60 capability_id_l1: BC-2870 capability_name: Patient Financial Services confidence: 0.8 evidence: POST /api/2.0/patients/{id}/outstanding_balance/ Update Outstanding Balance; schema PatientOutstandingBalance reason: Maintains a patient's outstanding balance in the billing API — patient financial services within provider revenue cycle. - tag: Sleep Orders spec_file: elation-health-sleep-orders-api-openapi.yml capability_id: BC-2830.20 capability_id_l1: BC-2830 capability_name: Computerised Provider Order Entry confidence: 0.8 evidence: POST /sleep_orders/ 'Create Sleep Order'; schemas SleepOrder, ICD10Code, DocumentResolutionState reason: CRUD over clinician-authored sleep study orders with diagnosis codes and document resolution state is computerised provider order entry for a diagnostic study. - tag: Billing spec_file: elation-health-billing-api-openapi.yml capability_id: BC-2870 capability_id_l1: BC-2870 capability_name: Healthcare Revenue Cycle Management confidence: 0.78 evidence: POST /billing_codes/ 'Create a billing code'; schemas 'BillingCode', 'BillingCodeCreate' reason: Despite the generic 'Billing' tag, the operations are CRUD on billing codes in a provider EHR — the code/charge master used for provider revenue cycle. L1 revenue cycle is safe; whether this is chargemaster stewardship or medical coding is ambiguous, so no L2. - tag: Ccda spec_file: elation-health-ccda-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.78 evidence: '"Create CCDA", "Get CCDA", "Get CCDA (CEHRT 2022)" keyed by {patient_id}' reason: Generation and retrieval of C-CDA continuity-of-care documents per patient, explicitly tied to CEHRT certification — provider-side health information exchange / interoperability operations. - tag: Lab Orders spec_file: elation-health-lab-orders-api-openapi.yml capability_id: BC-2830.20 capability_id_l1: BC-2830 capability_name: Computerised Provider Order Entry confidence: 0.78 evidence: '''Create Lab Order'', ''Retrieve the Printable Lab Order View'', schemas LabOrder, LabOrderSubmission, LabOrderSpecimen' reason: Creation, update and submission of laboratory orders for patients is provider order entry for diagnostics; specimen and submission schemas confirm real clinical ordering rather than a technical object. - tag: Cardiac Orders spec_file: elation-health-cardiac-orders-api-openapi.yml capability_id: BC-2830.20 capability_id_l1: BC-2830 capability_name: Computerised Provider Order Entry confidence: 0.75 evidence: '"Create Cardiac Order", "Update Cardiac Order"; schemas "CardiacOrder", "ICD10Code", "CardiacOrderTest"' reason: Full CRUD over clinician-created cardiac diagnostic orders with ICD-10 indication codes — computerised provider order entry for diagnostics within the EHR. - tag: Imaging Orders spec_file: elation-health-imaging-orders-api-openapi.yml capability_id: BC-2830.20 capability_id_l1: BC-2830 capability_name: Computerised Provider Order Entry confidence: 0.75 evidence: POST /imaging_orders/ create-imaging-order 'Create Imaging Order'; schemas ImagingOrderTest, ICD10Code, ImagingOrder reason: CRUD over provider-entered imaging orders with diagnosis codes and ordered tests inside an EHR — this is provider order entry for diagnostics, not the operation of imaging modalities themselves. - tag: Lab Order Compendiums spec_file: elation-health-lab-order-compendiums-api-openapi.yml capability_id: BC-2860.10 capability_id_l1: BC-2860 capability_name: Laboratory Services Management confidence: 0.75 evidence: 'POST /api/2.0/lab_order_compendiums/ Create Lab Order Compendium; schemas: LabOrderTestCompendium' reason: Maintenance of the orderable lab test compendium for a lab, a core laboratory services/orderables catalogue function. recovered_from: healthcare-vertical-edges.json - tag: Medication Order Templates spec_file: elation-health-medication-order-templates-api-openapi.yml capability_id: BC-2830.20 capability_id_l1: BC-2830 capability_name: Computerised Provider Order Entry confidence: 0.75 evidence: '''Create Medication Order Template'' / schemas MedOrderTemplate, Medication, MedicationDrugType, QtyUnitsEnum' reason: Manages reusable medication order templates (sig, drug, quantity units) used by clinicians when entering medication orders — the order-set/protocol content of provider order entry for medications. - tag: Patients spec_file: elation-health-patients-api-openapi.yml capability_id: BC-2800.20 capability_id_l1: BC-2800 capability_name: Patient Registration Management confidence: 0.75 evidence: POST /patients/ 'Create Patient'; schemas Patient, EmergencyContact, Address, Consent, PatientPreviousName, 'Get Insurance Cards' reason: Operations create, retrieve and update patient demographic/identity records including consent, emergency contacts and insurance cards — the stewardship of registration data for a patient in the EHR. Patient Registration Management is the closest fit; some overlap with master patient index stewardship keeps confidence below 0.8. - tag: Recurring Event Groups spec_file: elation-health-recurring-event-groups-api-openapi.yml capability_id: BC-2800.10 capability_id_l1: BC-2800 capability_name: Scheduling & Appointment Management confidence: 0.75 evidence: '"Create Recurring Event Group"; schemas "RecurringEventSchedule", "TimeSlotTypeEnum", "RepeatsEnum"; published in elation-scheduling-api.json' reason: Operations manage repeating calendar/time-slot definitions within the vendor's scheduling API, i.e. provider/resource appointment scheduling configuration. - tag: Sleep Order Tests spec_file: elation-health-sleep-order-tests-api-openapi.yml capability_id: BC-2830.20 capability_id_l1: BC-2830 capability_name: Computerised Provider Order Entry confidence: 0.75 evidence: POST /sleep_order_tests/ create-sleep-order-test 'Create Sleep Order Test'; schema SleepOrderTest tied to SleepOrder reason: Sleep order tests are the diagnostic test line items of a clinician-placed sleep study order in the EHR, i.e. provider order entry for diagnostics rather than any billing or scheduling function. - tag: Visit Note Templates spec_file: elation-health-visit-note-templates-api-openapi.yml capability_id: BC-2830.10 capability_id_l1: BC-2830 capability_name: Clinical Note Documentation confidence: 0.75 evidence: GET /visit_note_templates/ find-visit-note-templates; schemas VisitNoteTemplate, PatchedVisitNoteTemplate reason: Templates that structure clinician-authored visit notes are part of the clinical note documentation capability of the EHR. - tag: Allergy Documentation (NKDA) spec_file: elation-health-allergy-documentation-nkda-api-openapi.yml capability_id: BC-2830 capability_id_l1: BC-2830 capability_name: Clinical Documentation Management confidence: 0.72 evidence: POST /api/2.0/allergy_documentation/ 'Create Allergy Documentation'; schema 'PatientAllergyDocumentation' reason: 'Operations create, retrieve and delete structured allergy entries in the patient''s chart within a clinical EHR — this is documentation of the active clinical record (BC-2830). No sub-capability is clearly named: allergy lists are structured chart data rather than specifically notes, order entry or results review, so L2 is left null.' - tag: Appointment Rooms spec_file: elation-health-appointment-rooms-api-openapi.yml capability_id: BC-2800.10 capability_id_l1: BC-2800 capability_name: Scheduling & Appointment Management confidence: 0.72 evidence: GET /api/2.0/appointments/rooms/ — "List Appointment Rooms" reason: A reference list of rooms used for appointments in an EHR scheduling API; supports provider/resource scheduling. Thin (single read-only operation), so confidence is moderate. recovered_from: healthcare-vertical-edges.json - tag: Fills spec_file: elation-health-fills-api-openapi.yml capability_id: BC-2850 capability_id_l1: BC-2850 capability_name: Pharmacy & Medication Management confidence: 0.72 evidence: '''List Prescription Fills'' / ''Retrieve Prescription Fill''; schemas ''PrescriptionFill'', ''FillStatusEnum'', ''MedicationHistoryDownloadFill''' reason: Prescription fill records and medication-history fill data are provider-side medication management; the split between dispensing operations and reconciliation is ambiguous so only L1 is asserted. recovered_from: healthcare-vertical-edges.json - tag: Imaging Order Tests spec_file: elation-health-imaging-order-tests-api-openapi.yml capability_id: BC-2830.20 capability_id_l1: BC-2830 capability_name: Computerised Provider Order Entry confidence: 0.72 evidence: POST /imaging_order_tests/ "Create Imaging Order Test"; schema ImagingOrderTest reason: Creation and management of imaging order test entries, i.e. provider order entry for diagnostics, matching CPOE ("order entry for medications, diagnostics, and procedures"). - tag: Injections (BETA) spec_file: elation-health-injections-beta-api-openapi.yml capability_id: BC-2850.40 capability_id_l1: BC-2850 capability_name: Medication Administration & Reconciliation confidence: 0.72 evidence: 'schemas: Injection, SiteEnum, MethodEnum, DoseUnitEnum, ProcedureCodes, DiagnosisCode, Actor' reason: Injection records carrying administration site, method and dose unit plus procedure/diagnosis codes represent documented medication administration in the clinical record. - tag: Medications spec_file: elation-health-medications-api-openapi.yml capability_id: BC-2850 capability_id_l1: BC-2850 capability_name: Pharmacy & Medication Management confidence: 0.72 evidence: POST /medications/ create-medication Create Medication; schemas MedOrder, Fulfillment, MedicationDrugType, QtyUnitsEnum reason: CRUD over patient medications with medication orders and fulfillment schemas — provider-side medication management. Sub-capability ambiguous between prescribing/order entry and reconciliation, so L1 only. - tag: Allergies spec_file: elation-health-allergies-api-openapi.yml capability_id: BC-2830 capability_id_l1: BC-2830 capability_name: Clinical Documentation Management confidence: 0.7 evidence: 'POST /allergies/ create-allergy Create Allergy; schemas: PatientAllergy, PatientAllergySeverityEnum, AllergyStatus' reason: Elation is a clinical EHR and these operations maintain the structured patient allergy list within the active clinical record. That places it under Clinical Documentation Management; no single L2 (note authoring, order entry, results review) cleanly names structured allergy-list maintenance, so only the L1 is asserted. - tag: Allergy Documentation spec_file: elation-health-allergy-documentation-api-openapi.yml capability_id: BC-2830 capability_id_l1: BC-2830 capability_name: Clinical Documentation Management confidence: 0.7 evidence: POST /allergy_documentation/ create-allergy-documentation-nkda Create Allergy Documentation (NKDA) reason: Records clinician documentation of allergy status including 'No Known Drug Allergies' in the EHR chart, i.e. authoring of structured clinical documentation. L1 only, since the specific L2 sub-capabilities do not squarely cover structured allergy attestation. - tag: Caregaps spec_file: elation-health-caregaps-api-openapi.yml capability_id: BC-2880.10 capability_id_l1: BC-2880 capability_name: Risk Stratification & Identification confidence: 0.7 evidence: '"Create a new caregap." / "Modifies an existing caregap''s closed status." under /caregaps/api/{quality_program}/' reason: Operations create, list and close patient care gaps under a quality programme — identification and closure of care-gap populations, a population health capability rather than plumbing. - tag: Custom Blocks spec_file: elation-health-custom-blocks-api-openapi.yml capability_id: BC-2830.10 capability_id_l1: BC-2830 capability_name: Clinical Note Documentation confidence: 0.7 evidence: openapi description "This API supports the management of visit notes."; "List Custom Blocks"; schemas "DynamicFormAttrs", "AiGenerationInfo" reason: Custom blocks are structured/dynamic form components of visit notes, so the surface supports authoring of clinical notes. Only one read operation, hence moderate confidence. - tag: Delegate Permissions spec_file: elation-health-delegate-permissions-api-openapi.yml capability_id: BC-620.20 capability_id_l1: BC-620 capability_name: Identity & Access Management confidence: 0.7 evidence: '"Create Delegate Permission", "Delete Delegate Permission"; schemas "DelegatePermission", "PermissionTypeEnum"' reason: Manages delegation of access rights between users in the practice — access management plumbing rather than a clinical capability. - tag: Historical Medication Download Requests spec_file: elation-health-historical-medication-download-requests-api-openapi.yml capability_id: BC-2850 capability_id_l1: BC-2850 capability_name: Pharmacy & Medication Management confidence: 0.7 evidence: '''Create Medication History Download'', schema ''RxHistoryDownload''' reason: Requesting external medication history downloads is a pharmacy/medication management function (typically feeding medication reconciliation); L1 only given thin evidence on the exact sub-process. recovered_from: healthcare-vertical-edges.json - tag: Injections spec_file: elation-health-injections-api-openapi.yml capability_id: BC-2850.40 capability_id_l1: BC-2850 capability_name: Medication Administration & Reconciliation confidence: 0.7 evidence: GET /injections/{id}/ Get Injection; GET /injections/ Find Injections reason: Injections in an EHR represent administered injectable medications/immunizations recorded at the point of care, which maps to medication administration records. Read-only surface, so some ambiguity remains vs. clinical documentation. recovered_from: healthcare-vertical-edges.json - tag: Insurance Card spec_file: elation-health-insurance-card-api-openapi.yml capability_id: BC-2800.30 capability_id_l1: BC-2800 capability_name: Eligibility & Benefits Verification confidence: 0.7 evidence: 'POST /api/2.0/patients/{id}/insurance_cards/ Create Patients Insurance Card; schemas: InsuranceCard, InsuranceCardImage' reason: Capture and storage of patient insurance card images/data per patient, part of registration and coverage verification workflow at patient access. recovered_from: healthcare-vertical-edges.json - tag: Lab Facility Identifiers spec_file: elation-health-lab-facility-identifiers-api-openapi.yml capability_id: BC-2860.10 capability_id_l1: BC-2860 capability_name: Laboratory Services Management confidence: 0.7 evidence: 'GET /api/2.0/lab_facility_identifiers/ List Lab Facility Identifiers; schemas: FacilityIdentifier, BiDiLabConnection' reason: Configuration of laboratory facility identifiers and bidirectional lab connections used for lab ordering/result interfacing — laboratory services/LIS integration setup. recovered_from: healthcare-vertical-edges.json - tag: Lab Order Tests spec_file: elation-health-lab-order-tests-api-openapi.yml capability_id: BC-2860.10 capability_id_l1: BC-2860 capability_name: Laboratory Services Management confidence: 0.7 evidence: 'POST /api/2.0/lab_order_tests/ Create Lab Order Test; schemas: LabOrderTest, LabOrderAOEQuestion' reason: Definition of individual orderable lab tests with AOE questions — laboratory test catalogue management; could also be read as CPOE configuration, hence moderate confidence. recovered_from: healthcare-vertical-edges.json - tag: Problems spec_file: elation-health-problems-api-openapi.yml capability_id: BC-2830 capability_id_l1: BC-2830 capability_name: Clinical Documentation Management confidence: 0.7 evidence: POST /problems/ 'Create Problem'; schemas PatientProblem, Diagnosis, ImoCodeRelation, PatientProblemStatusEnum reason: Maintenance of the patient problem list with coded diagnoses in the active clinical record — clinical documentation of the patient's conditions. L1 Clinical Documentation Management; no single L2 (problem list spans note documentation and record content), so L2 left null. - tag: Pulmonary Orders spec_file: elation-health-pulmonary-orders-api-openapi.yml capability_id: BC-2830.20 capability_id_l1: BC-2830 capability_name: Computerised Provider Order Entry confidence: 0.7 evidence: POST /pulmonary_orders/ 'Create Pulmonary Order'; schemas PulmonaryOrder, PulmonaryOrderTest, ICD10Code, DocumentResolutionState reason: Full lifecycle of pulmonary diagnostic orders with associated diagnosis codes and tests — provider order entry for diagnostics (CPOE). Alternative reading as cardiopulmonary diagnostic service management keeps this at 0.7. - tag: Reports spec_file: elation-health-reports-api-openapi.yml capability_id: BC-2830.30 capability_id_l1: BC-2830 capability_name: Results Review & Endorsement confidence: 0.7 evidence: PATCH /reports/{id}/ "Sign Report"; schemas LabResult, LabTest, LabResultsGrid, AbnormalFlagEnum reason: Reports here carry lab test/result payloads and are signed by clinicians, i.e. routing, review and endorsement of diagnostic results; could alternatively read as diagnostic results management. recovered_from: healthcare-vertical-edges.json - tag: Visit Note Types spec_file: elation-health-visit-note-types-api-openapi.yml capability_id: BC-2830.10 capability_id_l1: BC-2830 capability_name: Clinical Note Documentation confidence: 0.7 evidence: POST /api/2.0/visit_note_types/ visit_note_types_create; schemas VisitNoteType, SnomedCode reason: Configuration of visit note categories coded to SNOMED supports authoring of clinical notes across encounter types; it is documentation configuration rather than a distinct capability. - tag: Vitals spec_file: elation-health-vitals-api-openapi.yml capability_id: BC-2830 capability_id_l1: BC-2830 capability_name: Clinical Documentation Management confidence: 0.7 evidence: '"Create Vitals", schemas VitalBP, VitalHR, VitalTemperature, VitalOxygen, VitalsCollection' reason: Capture of structured vital-sign observations into the patient record — documentation of clinical data. Left at L1 because it straddles note documentation and bedside care delivery. recovered_from: healthcare-vertical-edges.json - tag: patient chart import spec_file: elation-health-patient-chart-import-api-openapi.yml capability_id: BC-2900 capability_id_l1: BC-2900 capability_name: Health Information Management confidence: 0.7 evidence: '"This set of API resources allows you to import patient data into the Elation EMR"; "Add a new patient-chart-import to the associated data import request"' reason: Bulk ingestion of patient charts into the health record is health information management (record creation/migration). L2 left null because it sits between health record lifecycle and interoperability operations. recovered_from: healthcare-vertical-edges.json