Add patientIdentifier and setting Parameters To fhirR4ToManifest (Python & TypeScript)#321
Conversation
Add optional patientIdentifier parameter to ConvertFhirR4ToManifestRequest type in TypeScript Add optional patient_identifier parameter to fhir_r4_to_manifest method in Python Update parameter handling to pass patientIdentifier to the API endpoint
| - `content`: A FHIR R4 bundle | ||
| - `delimiter`: The delimiter to use in the CSV files. Allowed delimiters are | or ~ or ^ or ; Default delimiter is , | ||
| - `source`: The source of the FHIR R4 bundle to be included in the provenance file | ||
| - `patient_identifier`: A patient identifier to add to identifier list of patient resource in the FHIR bundle |
There was a problem hiding this comment.
- `patient_identifier`: The identifier to use as patient.identifier in patient manifest. If this is not provided, the default identifier from the patient resource in bundle is used
bindu-careev
left a comment
There was a problem hiding this comment.
Can you please add support for a setting query parameter in this same PR?
setting: This is a pre-coordinated value to allow an API user to control manifest output in terms of the columns included in a specific manifest file or the order of the columns. If not provided, expect the default manifest output, as documented.
|
@boris-careev once you add the clarification to the query param, we can get this merged. |
Done, waiting for your approval, @lynnfaraday, so merging is unblocked |
Description of Changes
Issue Link
This PR addresses the following issues:
https://github.com/CareEvolution/IO/issues/387
Security
REMINDER: All file contents are public.
Describe briefly what security risks you considered, why they don't apply, or how they've been mitigated.
Change Control Board (CCB) Approval
@careevolution/ccb.Testing/Validation
TODO: REPLACE WITH YOUR TESTING/VALIDATION PLAN
Backout Plan
Reverse merge-commit
Implementation Notes
TODO: REPLACE WITH IMPLEMENTATION NOTES
Documentation Updates
@careevolution/mdhd-docsor@careevolution/api-docs.TODO: REPLACE WITH A DESCRIPTION OF DOCUMENTATION UPDATES, if applicable
Reviewers
Minimally, a second set of eyes is needed ensure no non-public information is published. Consider also including subject-matter experts and editing/style reviewers.