slug: tebra provider: Tebra 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: 17 edges: - tag: AllergyIntolerance spec_file: tebra-allergyintolerance-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.8 evidence: SMART on FHIR (HL7 FHIR R4) read access to a patient's clinical health information held in the Tebra (formerly Kareo) platform ... satisfying USCDI v1 / ONC 21st Century Cures Act information-blocking requirements reason: A read-only US Core FHIR resource endpoint exposed for third-party app access to the patient record. The capability realised is operation of provider FHIR endpoints / patient-initiated data sharing, i.e. healthcare interoperability operations, rather than the clinical act of allergy assessment. - tag: CarePlan spec_file: tebra-careplan-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.8 evidence: GET /CarePlan getCarePlan Get care plan; SMART on FHIR (HL7 FHIR R4) read access to a patient's clinical health information ... built on the US Core Implementation Guide STU3 Release 3.1.1 reason: Read-only FHIR R4 exposure of the care plan resource for external app developers under the Cures Act rules — interoperability endpoint operation, not care-coordination workflow execution. - tag: Clinical spec_file: tebra-clinical-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.8 evidence: '"Tebra''s ONC / 21st Century Cures Act "patient access" API surface ... exposing USCDI-aligned clinical resources for a single authenticated patient"; key "generated by the patient from the Tebra Patient Portal under My Account > API Access Key"' reason: Read-only USCDI-aligned patient-access resource endpoints (problem list, medications, vitals, immunizations, etc.) exposed for patient-initiated data sharing. That is healthcare interoperability operations rather than the clinical documentation authoring workflow itself. - tag: CareTeam spec_file: tebra-careteam-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.75 evidence: '"SMART on FHIR (HL7 FHIR R4) read access to a patient''s clinical health information" ... GET /CareTeam getCareTeam "Get care team"' reason: A single read-only FHIR R4 endpoint published to satisfy USCDI v1 / ONC Cures Act information-blocking rules. The surface is a FHIR interoperability endpoint exposing record data, not a care-coordination workflow application, so Healthcare Interoperability Operations (FHIR endpoints, patient-initiated data sharing) is the honest mapping. - tag: Condition spec_file: tebra-condition-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.75 evidence: '"satisfying USCDI v1 / ONC 21st Century Cures Act information-blocking requirements"; GET /Condition getCondition' reason: Single read-only FHIR resource endpoint forming part of the ONC-mandated FHIR API; realises interoperability/data-sharing operations, not condition management workflow. - tag: DocumentReference spec_file: tebra-documentreference-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.75 evidence: GET /DocumentReference getDocumentReference within the FHIR surface "satisfying USCDI v1 / ONC 21st Century Cures Act information-blocking requirements" reason: FHIR DocumentReference read endpoint exposing clinical documents for external app access — health information exchange / patient-initiated data sharing. - tag: MedicationRequest spec_file: tebra-medicationrequest-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.75 evidence: '"SMART on FHIR (HL7 FHIR R4) read access to a patient''s clinical health information" ... GET /MedicationRequest getMedicationRequest' reason: A read-only FHIR R4 resource endpoint published to satisfy USCDI/Cures information-blocking rules; this is operation of a FHIR endpoint for health information exchange, not pharmacy dispensing or prescribing workflow. - tag: Device spec_file: tebra-device-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.72 evidence: GET /Device getDevice "Get implantable device" within "SMART on FHIR (HL7 FHIR R4) read access to a patient's clinical health information" reason: Read-only USCDI implantable-device FHIR resource; part of the provider's FHIR endpoint surface for patient data access, not medical device or asset management. - tag: Documents spec_file: tebra-documents-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.72 evidence: GET /patient/binary/summary getBinarySummary "Get clinical summary document" on the "patient access" API surface reason: Retrieval of the CCD-style clinical summary document by the authenticated patient; patient-initiated release of the record through an ONC-mandated API, i.e. interoperability operations. - tag: Encounter spec_file: tebra-encounter-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.72 evidence: GET /Encounter getEncounter within "SMART on FHIR (HL7 FHIR R4) read access to a patient's clinical health information" reason: Read-only FHIR Encounter endpoint for USCDI patient access; the operation exposes record data via a FHIR endpoint rather than performing encounter/registration management. - tag: Immunization spec_file: tebra-immunization-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.72 evidence: GET /Immunization getImmunization within "read access to a patient's clinical health information ... US Core Implementation Guide STU3" reason: Read-only FHIR immunization resource exposed for USCDI patient access; interoperability data sharing rather than immunisation programme delivery. - tag: Observation spec_file: tebra-observation-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.72 evidence: GET /Observation getObservation — "SMART on FHIR (HL7 FHIR R4) read access to a patient's clinical health information held in the Tebra ... platform" reason: Read-only FHIR resource exposure under US Core / USCDI for third-party apps; the capability realised is FHIR endpoint / interoperability operation rather than diagnostic results production. - tag: DiagnosticReport spec_file: tebra-diagnosticreport-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.7 evidence: GET /DiagnosticReport getDiagnosticReport "Get diagnostic report"; "read access to a patient's clinical health information ... US Core Implementation Guide" reason: Read-only FHIR endpoint exposing already-finalised diagnostic reports for patient access; this is interoperability distribution of the record rather than laboratory/imaging service operations or results validation workflow. - tag: Medication spec_file: tebra-medication-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.7 evidence: GET /Medication getMedication within the SMART on FHIR US Core read-only API "satisfying USCDI v1 / ONC ... requirements" reason: Read-only FHIR Medication resource for patient data access; this is an interoperability endpoint, not pharmacy dispensing or formulary management. - tag: Patient spec_file: tebra-patient-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.7 evidence: GET /Patient getPatient (tebra-fhir-api-openapi.yml) and GET /patient getPatient; schemas FHIRBundle, Patient reason: Patient demographic retrieval exposed through the FHIR/US Core read surface for third-party patient-access apps; interoperability operation rather than registration or MPI stewardship, which would require write/merge operations. - tag: Procedure spec_file: tebra-procedure-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.7 evidence: GET /Procedure getProcedure — "read access to a patient's clinical health information ... satisfying USCDI v1 / ONC 21st Century Cures Act information-blocking requirements" reason: Read-only clinical resource served over the US Core FHIR API; interoperability operations, not surgical care delivery. - tag: Provenance spec_file: tebra-provenance-api-openapi.yml capability_id: BC-2900.60 capability_id_l1: BC-2900 capability_name: Healthcare Interoperability Operations confidence: 0.7 evidence: GET /Provenance getProvenance; "SMART on FHIR (HL7 FHIR R4) read access" built on US Core reason: US Core Provenance is required metadata for FHIR data sharing; squarely an interoperability endpoint operation.