[Bug] Token Searching is not Exact matching (Intent on MedicationRequest)
floofydoug opened this issue · 4 comments
Describe the bug
A request with a token of "order" for Intent in resource MedicationRequest returns with the wrong number of expected resources.
https://fg93b2lt5i.execute-api.us-east-1.amazonaws.com/dev/tenant/sitetenant/MedicationRequest?intent=order&patient=f48ca782-ab28-49ac-9303-00e50c33bf37
Expected Resources: 1.
Received Resources: 2.
To Reproduce
Steps to reproduce the behavior:
- create 2 MedicationRequest resources.
- Have 1 resource with the intent code: "order"
- Have the other resource created with the intent code: "original-order"
- run a search with these params:
your-server.com/dev/tenant/sitetenant/MedicationRequest?intent=order&patient=f48ca782-ab28-49ac-9303-00e50c33bf37
Expected behavior
Expect "intent" which is a token type to be filtering on Exact.
Expected 1 result.
Screenshots
If applicable, add screenshots to help explain your problem.
Versions (please complete the following information):
US CORE 3.1.1, FWOA SmartLine deployment v3.1.1
Reproduced and added to our backlog. Thanks!
I am terrible with elasticsearch. However, I was able to get by the the intent problem by forking the search-es repo and adding the following to the tokenQuery:
~~if (compiled.path === 'intent' && code === 'order') {
queries.push({
bool: {
must: {
term: { 'intent.keyword': 'order' },
},
},
});
} else if (compiled.path === 'intent' && code === 'original-order') {
queries.push({
bool: {
must: {
term: { 'intent.keyword': 'original-order' },
},
},
});~~
this is not a very elegant solution, but for anyone else stuck testing for g10.
See below comment.
Ah. It turns out 4.13 Single Patient API Medication Requests tests much more than just order vs original-order. There were intent queries for reflex-order and instance-order too. As I am running the SMARTline branch, i've noted my steps below.
I forked FWOA-search-es and I've modified the thetokenQuery.ts
with the following:
if (compiled.path === 'intent') {
queries.push({
bool: {
must: {
term: { 'intent.keyword': code },
},
},
});
} else {
queries.push({
multi_match: {
fields,
query: code,
lenient: true,
},
});
}
Then i ran yarn run release
. committed that. then modified my package.json on FWOA-deployment to include my fork instead of the default library. Then did the following inside of deployment repo:
- `rm -rf node_modules/fhir-works-on-aws-search-es`
- `rm yarn.lock`
- `yarn install`
- `yarn deploy --all parameters here (multi tenancy, profile, issuerendpoint`
- in Inferno ONC Certification (g)(10) Standardized API V.3.3.1, run step one: Standalone patient app in order to secure an access token.
- Then you can run step 4, Single Patient App to pass medication requests.
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] (mailto:security@amazon.com). If you are new to this solution, we advise you to explore using [HealthLake] (https://aws.amazon.com/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.