feat(api-sdk): added cohort methods to api-sdk #4089
Conversation
Part of ENG-420 Signed-off-by: Ramil Garipov <ramil@metriport.com>
WalkthroughThis change introduces full cohort management capabilities to the Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant MetriportMedicalA
8000
pi
participant BackendAPI
Client->>MetriportMedicalApi: createCohort(data)
MetriportMedicalApi->>BackendAPI: POST /cohort
BackendAPI-->>MetriportMedicalApi: CohortDTO
MetriportMedicalApi-->>Client: CohortDTO
Client->>MetriportMedicalApi: updateCohort(cohort)
MetriportMedicalApi->>BackendAPI: PUT /cohort/{id} (with ETag)
BackendAPI-->>MetriportMedicalApi: CohortDTO
MetriportMedicalApi-->>Client: CohortDTO
Client->>MetriportMedicalApi: assignPatientsToCohort(cohortId, data)
MetriportMedicalApi->>BackendAPI: POST /cohort/{id}/patient
BackendAPI-->>MetriportMedicalApi: CohortWithPatientIdsAndCountDTO
MetriportMedicalApi-->>Client: CohortWithPatientIdsAndCountDTO
Client->>MetriportMedicalApi: removePatientsFromCohort(cohortId, data)
MetriportMedicalApi->>BackendAPI: DELETE /cohort/{id}/patient
BackendAPI-->>MetriportMedicalApi: PatientUnassignmentResponse
MetriportMedicalApi-->>Client: PatientUnassignmentResponse
Possibly related PRs
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
npm error code ERR_SSL_WRONG_VERSION_NUMBER ✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/api-sdk/src/medical/client/metriport.ts (2)
680-680: Remove debugging console.log statement.This console.log appears to be leftover from development and should be removed according to the coding guidelines which state to avoid using
console.login packages other than utils, infra and shared.- console.log("RESP DATA IS", resp.data);
715-715: Remove debugging console.log statement.This console.log appears to be leftover from development and should be removed according to the coding guidelines.
- console.log("RESP DATA IS", resp.data);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/api-sdk/src/medical/client/metriport.ts(3 hunks)packages/api-sdk/src/medical/models/cohort.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
`**/*`: Use eslint to enforce code style Use prettier to format code Max column ...
**/*: Use eslint to enforce code style
Use prettier to format code
Max column length is 100 chars
Multi-line comments use /** */
Top-level comments go after the import (save pre-import to basic file header, like license)
Move literals to constants declared after imports when possible
File names: kebab-case
📄 Source: CodeRabbit Inference Engine (.cursorrules)
List of files the instruction was applied to:
packages/api-sdk/src/medical/models/cohort.tspackages/api-sdk/src/medical/client/metriport.ts
`**/*.ts`: - Use the Onion Pattern to organize a package's code in layers - Try ...
**/*.ts: - Use the Onion Pattern to organize a package's code in layers
- Try to use immutable code and avoid sharing state across different functions, objects, and systems
- Try to build code that's idempotent whenever possible
- Prefer functional programming style functions: small, deterministic, 1 input, 1 output
- Minimize coupling / dependencies
- Avoid modifying objects received as parameter
- Only add comments to code to explain why something was done, not how it works
- Naming
- classes, enums:
PascalCase- constants, variables, functions:
camelCase- file names:
kebab-case- table and column names:
snake_case- Use meaningful names, so whoever is reading the code understands what it means
- Don’t use negative names, like
notEnabled, preferisDisabled- For numeric values, if the type doesn’t convey the unit, add the unit to the name
- Typescript
- Use types
- Prefer
constinstead oflet- Avoid
anyand casting fromanyto other types- Type predicates: only applicable to narrow down the type, not to force a complete type conversion
- Prefer deconstructing parameters for functions instead of multiple parameters that might be of
the same type- Don’t use
nullinside the app, only on code interacting with external interfaces/services,
like DB and HTTP; convert toundefinedbefore sending inwards into the code- Use
async/awaitinstead of.then()- Use the strict equality operator
===, don’t use abstract equality operator==- When calling a Promise-returning function asynchronously (i.e., not awaiting), use
.catch()to
handle errors (seeprocessAsyncErrorandemptyFunctiondepending on the case)- Date and Time
- Always use
buildDayjs()to createdayjsinstances- Prefer
dayjs.duration(...)to create duration consts and keep them asduration- Prefer Nullish Coalesce (??) than the OR operator (||) to provide a default value
- Avoid creating arrow functions
- Use truthy syntax instead of
in- i.e.,if (data.link)notif ('link' in data)- Error handling
- Pass the original error as the new one’s
causeso the stack trace is persisted- Error messages should have a static message - add dynamic data to MetriportError's
additionalInfoprop- Avoid sending multiple events to Sentry for a single error
- Global constants and variables
- Move literals to constants declared after imports when possible (avoid magic numbers)
- Avoid shared, global objects
- Avoid using
console.logandconsole.errorin packages other than utils, infra and shared,
and try to useout().loginstead- Avoid multi-line logs
- don't send objects as a second parameter to
console.log()orout().log()- don't create multi-line strings when using
JSON.stringify()- Use
eslintto enforce code style- Use
prettierto format code- max column length is 100 chars
- multi-line comments use
/** */- scripts: top-level comments go after the import
⚙️ Source: CodeRabbit Configuration File
List of files the instruction was applied to:
packages/api-sdk/src/medical/models/cohort.tspackages/api-sdk/src/medical/client/metriport.ts
🧠 Learnings (1)
packages/api-sdk/src/medical/models/cohort.ts (1)
Learnt from: RamilGaripov
PR: metriport/metriport#3976
File: packages/api/src/routes/medical/patient.ts:541-543
Timestamp: 2025-06-18T21:05:22.256Z
Learning: In packages/api/src/routes/medical/patient.ts, inline schema definitions like cohortIdSchema are acceptable and don't need to be moved to separate schema files when the user prefers to keep them inline.
🔇 Additional comments (10)
packages/api-sdk/src/medical/models/cohort.ts (1)
1-61: LGTM! Well-structured schema definitions with good type safety.The cohort model file follows excellent patterns with comprehensive Zod schema definitions and proper TypeScript type exports. The schema hierarchy progresses logically from basic cohort data to composite types including patient counts and IDs. The manual
PatientAssignmentRequesttype provides appropriate flexibility for either specific patient IDs or bulk operations.packages/api-sdk/src/medical/client/metriport.ts (9)
20-32: LGTM! Proper imports for cohort functionality.The new imports are well-organized and include all necessary types and schemas for the cohort management methods.
70-70: LGTM! Consistent URL constant pattern.The
COHORT_URLconstant follows the established naming convention and pattern used by other endpoint constants in the file.
670-682: LGTM! Well-implemented createCohort method.The method follows established patterns with proper error handling, response validation using Zod schema, and comprehensive JSDoc documentation. The implementation is consistent with other create methods in the class.
684-696: LGTM! Proper updateCohort implementation with ETag support.The method correctly implements the update pattern with ETag header support for optimistic locking, following the same approach used by other update methods in the codebase.
698-705: LGTM! Simple and correct deleteCohort implementation.The delete method follows the established pattern for deletion operations with appropriate documentation about the prerequisite of unassigning patients first.
707-717: LGTM! Well-implemented listCohorts method.The method properly handles the list operation with appropriate fallback for empty responses and proper schema validation. The implementation follows established patterns for list methods.
719-729: LGTM! Comprehensive getCohort implementation.The method correctly retrieves detailed cohort information including patient IDs and count, with proper error handling and schema validation.
731-745: LGTM! Well-designed patient assignment method.The method properly handles bulk patient assignment with flexible input options (specific patient IDs or all patients) and returns comprehensive cohort information after the operation.
747-763: LGTM! Proper patient removal implementation.The method correctly uses DELETE with request body via the
dataproperty for bulk patient removal operations, following HTTP best practices and providing appropriate response information.
Part of ENG-526
Issues:
Description
metriport.tsSDK clientTesting
Release Plan
Summary by CodeRabbit
New Features
Documentation