You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 13, 2023. It is now read-only.
Is your feature request related to a problem? Please describe.
The Payer-to-Payer requirement allows a Member to authorize a Payer (the 'New' Payer) to access the user's data at another Payer (the 'Old' Payer). The most common use case is when a Member changes health plans, however, the Member changing plans is not a requirement. They could, for example, be part of two health plans.
The Payer-to-Payer requirement is vague on how this should work, particularly in how the Member would be able to grant the access, however, there are FHIR Server needs two capabilities we will need to implement this: Patient Everything, and Bulk Upload.
Describe the solution you'd like
Support Patient Everything: The Patient Everything operation extends the FHIR Patient Endpoint to allow requests for all patient data. The response is a bundle of type "searchset". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user.
When this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made asynchronously, and associated with bulk data formats. The operation to access multiple patient records at once is not required for Payer to Payer.. The requirement states that a single patient should return data synchronously as a bundle, however, this may return thousands of records and potentially timeout -- an asynchronous operation should be strongly considered.
Our preliminary design is to write the information to an S3 bucket where it can be read using a signed URL with TTL.
Additionally, the OAUTH2 scopes must be used to determine which records will be returned. Typically, the scopes will provide access to the Clinical Records (e.g. Patient/Observation.read, etc) for the Patient and exclude Payment Records (Patient/ExplanationOfBenefit.read, etc.)
Describe alternatives you've considered
Data could be extracted by calling all endpoints and combining the data.
Additional context
None.
The text was updated successfully, but these errors were encountered:
FHIR Works on AWS has been moved to maintenance mode. While in maintenance, we will not add any new features to this solution. All security issues should be reported directly to AWS Security at aws-security@amazon.com. If you are new to this solution, we advise you to explore using HealthLake, which is our managed service for building FHIR based transactional and analytics applications. You can get started by contacting your AWS Account team. If you are an existing customer
of FHIR Works on AWS, and have additional questions or need immediate help, please reach out to fwoa-migration-support@amazon.com or contact your AWS Account team.
Is your feature request related to a problem? Please describe.
The Payer-to-Payer requirement allows a Member to authorize a Payer (the 'New' Payer) to access the user's data at another Payer (the 'Old' Payer). The most common use case is when a Member changes health plans, however, the Member changing plans is not a requirement. They could, for example, be part of two health plans.
The Payer-to-Payer requirement is vague on how this should work, particularly in how the Member would be able to grant the access, however, there are FHIR Server needs two capabilities we will need to implement this: Patient Everything, and Bulk Upload.
Describe the solution you'd like
Support Patient Everything: The Patient Everything operation extends the FHIR Patient Endpoint to allow requests for all patient data. The response is a bundle of type "searchset". At a minimum, the patient resource(s) itself is returned, along with any other resources that the server has that are related to the patient(s), and that are available for the given user.
When this operation is used to access multiple patient records at once, the return bundle could be rather a lot of data; servers may choose to require that such requests are made asynchronously, and associated with bulk data formats. The operation to access multiple patient records at once is not required for Payer to Payer.. The requirement states that a single patient should return data synchronously as a bundle, however, this may return thousands of records and potentially timeout -- an asynchronous operation should be strongly considered.
Our preliminary design is to write the information to an S3 bucket where it can be read using a signed URL with TTL.
Additionally, the OAUTH2 scopes must be used to determine which records will be returned. Typically, the scopes will provide access to the Clinical Records (e.g. Patient/Observation.read, etc) for the Patient and exclude Payment Records (Patient/ExplanationOfBenefit.read, etc.)
Describe alternatives you've considered
Data could be extracted by calling all endpoints and combining the data.
Additional context
None.
The text was updated successfully, but these errors were encountered: