**/*.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, prefer isDisabled
  • For numeric values, if the type doesn’t convey the unit, add the unit to the name
• Typescript
  • Use types
  • Prefer const instead of let
  • Avoid any and casting from any to 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 null inside the app, only on code interacting with external interfaces/services,
    like DB and HTTP; convert to undefined before sending inwards into the code
  • Use async/await instead 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 (see processAsyncError and emptyFunction depending on the case)
  • Date and Time
    • Always use buildDayjs() to create dayjs instances
    • Prefer dayjs.duration(...) to create duration consts and keep them as duration
• 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) not if ('link' in data)
• Error handling
  • Pass the original error as the new one’s cause so the stack trace is persisted
  • Error messages should have a static message - add dynamic data to MetriportError's additionalInfo prop
  • 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.log and console.error in packages other than utils, infra and shared,
  and try to use out().log instead
• Avoid multi-line logs
  • don't send objects as a second parameter to console.log() or out().log()
  • don't create multi-line strings when using JSON.stringify()
• Use eslint to enforce code style
• Use prettier to format code
• max column length is 100 chars
• multi-line comments use /** */
• scripts: top-level comments go after the import

• packages/shared/src/interface/external/ehr/canvas/index.ts
• packages/api/src/external/ehr/athenahealth/command/write-back/medication.ts
• packages/api/src/external/ehr/canvas/command/write-back/allergy.ts
• packages/api/src/external/ehr/canvas/command/write-back/medication.ts
• packages/shared/src/interface/external/ehr/canvas/allergen.ts
• packages/api/src/external/ehr/canvas/command/write-back/vitals.ts
• packages/api/src/external/ehr/athenahealth/command/write-back/vitals.ts
• packages/api/src/external/ehr/canvas/command/write-back/immunization.ts
• packages/core/src/external/ehr/shared.ts
• packages/api/src/external/ehr/canvas/command/write-back/condition.ts
• packages/api/src/routes/ehr/canvas/patient.ts
• packages/core/src/external/ehr/canvas/index.ts
• packages/core/src/external/ehr/athenahealth/index.ts

packages/core/src/external/ehr/shared.ts (1)

• MedicationWithRefs (297-302)

packages/core/src/external/ehr/shared.ts (1)

• GroupedVitals (304-307)

packages/core/src/external/ehr/shared.ts (10)

• MedicationWithRefs (297-302)
• getMedicationRxnormCoding (321-329)
• getAllergyIntoleranceSubstanceRxnormCoding (567-578)
• GroupedVitals (304-307)
• getImmunizationCvxCoding (380-388)
• getImmunizationAdministerDate (396-404)
• getAllergyIntoleranceOnsetDate (594-598)
• DataPoint (314-319)
• getObservationLoincCoding (477-485)
• getObservationResultStatus (520-524)

packages/shared/src/index.ts (2)

• BadRequestError (40-40)
• NotFoundError (42-42)

packages/lambdas/src/shared/capture.ts (1)

• capture (18-103)

packages/shared/src/interface/external/ehr/fhir-resource.ts (2)

• EhrFhirResourceBundle (26-26)
• ehrFhirResourceBundleSchema (21-25)

packages/core/src/fhir-deduplication/resources/observation-shared.ts (1)

• ObservationStatus (28-28)

packages/core/src/fhir-deduplication/shared.ts (1)

• fetchCodingCodeOrDisplayOrSystem (452-475)

**/*.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, prefer isDisabled
  • For numeric values, if the type doesn’t convey the unit, add the unit to the name
• Typescript
  • Use types
  • Prefer const instead of let
  • Avoid any and casting from any to 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 null inside the app, only on code interacting with external interfaces/services,
    like DB and HTTP; convert to undefined before sending inwards into the code
  • Use async/await instead 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 (see processAsyncError and emptyFunction depending on the case)
  • Date and Time
    • Always use buildDayjs() to create dayjs instances
    • Prefer dayjs.duration(...) to create duration consts and keep them as duration
• 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) not if ('link' in data)
• Error handling
  • Pass the original error as the new one’s cause so the stack trace is persisted
  • Error messages should have a static message - add dynamic data to MetriportError's additionalInfo prop
  • 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.log and console.error in packages other than utils, infra and shared,
  and try to use out().log instead
• Avoid multi-line logs
  • don't send objects as a second parameter to console.log() or out().log()
  • don't create multi-line strings when using JSON.stringify()
• Use eslint to enforce code style
• Use prettier to format code
• max column length is 100 chars
• multi-line comments use /** */
• scripts: top-level comments go after the import

• packages/core/src/external/ehr/canvas/index.ts

**/*.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, prefer isDisabled
  • For numeric values, if the type doesn’t convey the unit, add the unit to the name
• Typescript
  • Use types
  • Prefer const instead of let
  • Avoid any and casting from any to 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 null inside the app, only on code interacting with external interfaces/services,
    like DB and HTTP; convert to undefined before sending inwards into the code
  • Use async/await instead 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 (see processAsyncError and emptyFunction depending on the case)
  • Date and Time
    • Always use buildDayjs() to create dayjs instances
    • Prefer dayjs.duration(...) to create duration consts and keep them as duration
• 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) not if ('link' in data)
• Error handling
  • Pass the original error as the new one’s cause so the stack trace is persisted
  • Error messages should have a static message - add dynamic data to MetriportError's additionalInfo prop
  • 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.log and console.error in packages other than utils, infra and shared,
  and try to use out().log instead
• Avoid multi-line logs
  • don't send objects as a second parameter to console.log() or out().log()
  • don't create multi-line strings when using JSON.stringify()
• Use eslint to enforce code style
• Use prettier to format code
• max column length is 100 chars
• multi-line comments use /** */
• scripts: top-level comments go after the import

• packages/core/src/external/ehr/canvas/index.ts

packages/core/src/external/ehr/shared.ts (12)

• ApiConfig (75-80)
• MedicationWithRefs (297-302)
• getMedicationRxnormCoding (321-329)
• getAllergyIntoleranceSubstanceRxnormCoding (567-578)
• GroupedVitals (304-307)
• formatDate (92-98)
• getImmunizationCvxCoding (380-388)
• getImmunizationAdministerDate (396-404)
• getAllergyIntoleranceOnsetDate (594-598)
• DataPoint (314-319)
• getObservationLoincCoding (477-485)
• getObservationResultStatus (520-524)

packages/shared/src/index.ts (2)

• BadRequestError (40-40)
• NotFoundError (42-42)

packages/lambdas/src/shared/capture.ts (1)

• capture (18-103)

packages/shared/src/interface/external/ehr/fhir-resource.ts (2)

• EhrFhirResourceBundle (26-26)
• ehrFhirResourceBundleSchema (21-25)

packages/core/src/fhir-deduplication/resources/observation-shared.ts (1)

• ObservationStatus (28-28)

packages/core/src/fhir-deduplication/shared.ts (1)

• fetchCodingCodeOrDisplayOrSystem (452-475)

**/*.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, prefer isDisabled
  • For numeric values, if the type doesn’t convey the unit, add the unit to the name
• Typescript
  • Use types
  • Prefer const instead of let
  • Avoid any and casting from any to 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 null inside the app, only on code interacting with external interfaces/services,
    like DB and HTTP; convert to undefined before sending inwards into the code
  • Use async/await instead 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 (see processAsyncError and emptyFunction depending on the case)
  • Date and Time
    • Always use buildDayjs() to create dayjs instances
    • Prefer dayjs.duration(...) to create duration consts and keep them as duration
• 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) not if ('link' in data)
• Error handling
  • Pass the original error as the new one’s cause so the stack trace is persisted
  • Error messages should have a static message - add dynamic data to MetriportError's additionalInfo prop
  • 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.log and console.error in packages other than utils, infra and shared,
  and try to use out().log instead
• Avoid multi-line logs
  • don't send objects as a second parameter to console.log() or out().log()
  • don't create multi-line strings when using JSON.stringify()
• Use eslint to enforce code style
• Use prettier to format code
• max column length is 100 chars
• multi-line comments use /** */
• scripts: top-level comments go after the import

• packages/core/src/external/ehr/athenahealth/index.ts
• packages/core/src/external/ehr/canvas/index.ts

**/*.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, prefer isDisabled
  • For numeric values, if the type doesn’t convey the unit, add the unit to the name
• Typescript
  • Use types
  • Prefer const instead of let
  • Avoid any and casting from any to 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 null inside the app, only on code interacting with external interfaces/services,
    like DB and HTTP; convert to undefined before sending inwards into the code
  • Use async/await instead 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 (see processAsyncError and emptyFunction depending on the case)
  • Date and Time
    • Always use buildDayjs() to create dayjs instances
    • Prefer dayjs.duration(...) to create duration consts and keep them as duration
• 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) not if ('link' in data)
• Error handling
  • Pass the original error as the new one’s cause so the stack trace is persisted
  • Error messages should have a static message - add dynamic data to MetriportError's additionalInfo prop
  • 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.log and console.error in packages other than utils, infra and shared,
  and try to use out().log instead
• Avoid multi-line logs
  • don't send objects as a second parameter to console.log() or out().log()
  • don't create multi-line strings when using JSON.stringify()
• Use eslint to enforce code style
• Use prettier to format code
• max column length is 100 chars
• multi-line comments use /** */
• scripts: top-level comments go after the import

• packages/core/src/external/ehr/canvas/index.ts

**/*.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, prefer isDisabled
  • For numeric values, if the type doesn’t convey the unit, add the unit to the name
• Typescript
  • Use types
  • Prefer const instead of let
  • Avoid any and casting from any to 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 null inside the app, only on code interacting with external interfaces/services,
    like DB and HTTP; convert to undefined before sending inwards into the code
  • Use async/await instead 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 (see processAsyncError and emptyFunction depending on the case)
  • Date and Time
    • Always use buildDayjs() to create dayjs instances
    • Prefer dayjs.duration(...) to create duration consts and keep them as duration
• 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) not if ('link' in data)
• Error handling
  • Pass the original error as the new one’s cause so the stack trace is persisted
  • Error messages should have a static message - add dynamic data to MetriportError's additionalInfo prop
  • 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.log and console.error in packages other than utils, infra and shared,
  and try to use out().log instead
• Avoid multi-line logs
  • don't send objects as a second parameter to console.log() or out().log()
  • don't create multi-line strings when using JSON.stringify()
• Use eslint to enforce code style
• Use prettier to format code
• max column length is 100 chars
• multi-line comments use /** */
• scripts: top-level comments go after the import

• packages/core/src/external/ehr/canvas/index.ts

packages/core/src/external/ehr/shared.ts (11)

• ApiConfig (75-80)
• MedicationWithRefs (297-302)
• getMedicationRxnormCoding (321-329)
• getAllergyIntoleranceSubstanceRxnormCoding (567-578)
• GroupedVitals (304-307)
• formatDate (92-98)
• getImmunizationCvxCoding (380-388)
• getImmunizationAdministerDate (396-404)
• DataPoint (314-319)
• getObservationLoincCoding (477-485)
• getObservationResultStatus (520-524)

packages/shared/src/index.ts (2)

• BadRequestError (40-40)
• NotFoundError (42-42)

packages/lambdas/src/shared/capture.ts (1)

• capture (18-103)

packages/shared/src/interface/external/ehr/fhir-resource.ts (1)

• ehrFhirResourceBundleSchema (21-25)

packages/core/src/fhir-deduplication/resources/observation-shared.ts (1)

• ObservationStatus (28-28)

packages/core/src/fhir-deduplication/shared.ts (1)

• fetchCodingCodeOrDisplayOrSystem (452-475)

packages/shared/src/common/date.ts (1)

• buildDayjs (86-88)

**/*.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, prefer isDisabled
  • For numeric values, if the type doesn’t convey the unit, add the unit to the name
• Typescript
  • Use types
  • Prefer const instead of let
  • Avoid any and casting from any to 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 null inside the app, only on code interacting with external interfaces/services,
    like DB and HTTP; convert to undefined before sending inwards into the code
  • Use async/await instead 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 (see processAsyncError and emptyFunction depending on the case)
  • Date and Time
    • Always use buildDayjs() to create dayjs instances
    • Prefer dayjs.duration(...) to create duration consts and keep them as duration
• 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) not if ('link' in data)
• Error handling
  • Pass the original error as the new one’s cause so the stack trace is persisted
  • Error messages should have a static message - add dynamic data to MetriportError's additionalInfo prop
  • 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.log and console.error in packages other than utils, infra and shared,
  and try to use out().log instead
• Avoid multi-line logs
  • don't send objects as a second parameter to console.log() or out().log()
  • don't create multi-line strings when using JSON.stringify()
• Use eslint to enforce code style
• Use prettier to format code
• max column length is 100 chars
• multi-line comments use /** */
• scripts: top-level comments go after the import

• packages/core/src/external/ehr/canvas/index.ts

**/*.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, prefer isDisabled
  • For numeric values, if the type doesn’t convey the unit, add the unit to the name
• Typescript
  • Use types
  • Prefer const instead of let
  • Avoid any and casting from any to 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 null inside the app, only on code interacting with external interfaces/services,
    like DB and HTTP; convert to undefined before sending inwards into the code
  • Use async/await instead 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 (see processAsyncError and emptyFunction depending on the case)
  • Date and Time
    • Always use buildDayjs() to create dayjs instances
    • Prefer dayjs.duration(...) to create duration consts and keep them as duration
• 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) not if ('link' in data)
• Error handling
  • Pass the original error as the new one’s cause so the stack trace is persisted
  • Error messages should have a static message - add dynamic data to MetriportError's additionalInfo prop
  • 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.log and console.error in packages other than utils, infra and shared,
  and try to use out().log instead
• Avoid multi-line logs
  • don't send objects as a second parameter to console.log() or out().log()
  • don't create multi-line strings when using JSON.stringify()
• Use eslint to enforce code style
• Use prettier to format code
• max column length is 100 chars
• multi-line comments use /** */
• scripts: top-level comments go after the import

• packages/core/src/external/ehr/canvas/index.ts

packages/core/src/external/ehr/shared.ts (10)

• MedicationWithRefs (297-302)
• getMedicationRxnormCoding (321-329)
• getAllergyIntoleranceSubstanceRxnormCoding (567-578)
• GroupedVitals (304-307)
• getImmunizationCvxCoding (380-388)
• getImmunizationAdministerDate (396-404)
• getAllergyIntoleranceOnsetDate (594-598)
• DataPoint (314-319)
• getObservationLoincCoding (477-485)
• getObservationResultStatus (520-524)

packages/shared/src/index.ts (2)

• BadRequestError (40-40)
• NotFoundError (42-42)

packages/lambdas/src/shared/capture.ts (1)

• capture (18-103)

packages/shared/src/interface/external/ehr/fhir-resource.ts (2)

• EhrFhirResourceBundle (26-26)
• ehrFhirResourceBundleSchema (21-25)

packages/core/src/fhir-deduplication/resources/observation-shared.ts (1)

• ObservationStatus (28-28)

packages/core/src/fhir-deduplication/shared.ts (1)

• fetchCodingCodeOrDisplayOrSystem (452-475)

packages/shared/src/common/date.ts (1)

• buildDayjs (86-88)

**/*.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, prefer isDisabled
  • For numeric values, if the type doesn’t convey the unit, add the unit to the name
• Typescript
  • Use types
  • Prefer const instead of let
  • Avoid any and casting from any to 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 null inside the app, only on code interacting with external interfaces/services,
    like DB and HTTP; convert to undefined before sending inwards into the code
  • Use async/await instead 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 (see processAsyncError and emptyFunction depending on the case)
  • Date and Time
    • Always use buildDayjs() to create dayjs instances
    • Prefer dayjs.duration(...) to create duration consts and keep them as duration
• 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) not if ('link' in data)
• Error handling
  • Pass the original error as the new one’s cause so the stack trace is persisted
  • Error messages should have a static message - add dynamic data to MetriportError's additionalInfo prop
  • 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.log and console.error in packages other than utils, infra and shared,
  and try to use out().log instead
• Avoid multi-line logs
  • don't send objects as a second parameter to console.log() or out().log()
  • don't create multi-line strings when using JSON.stringify()
• Use eslint to enforce code style
• Use prettier to format code
• max column length is 100 chars
• multi-line comments use /** */
• scripts: top-level comments go after the import

• packages/core/src/external/ehr/canvas/index.ts