search

CDCgov / phdi

https://cdcgov.github.io/dibbs-site/
Creative Commons Zero v1.0 Universal
29 stars 11 forks source link

Mapping message parser to eCR viewer #960

Open robertandremitchell opened 7 months ago

robertandremitchell commented 7 months ago

Essentially a cross-reference of what is returned in message_parser to the document here: https://docs.google.com/spreadsheets/d/1S-swX3cmwbwEpS10UxTGeklp9s4CTw7Wwu3BQssy-8Y/edit#gid=0.

Dan recommends we use the following json crosswalk as the most up to date reference for what message_parser pulls out: https://github.com/CDCgov/phdi-azure/blob/main/scripts/Synapse/config/ecr_datastore_config.json.

I am noting down which requested fields do not appear to be listed in the message_parser.

For the MVP, I think we could do the following:

  1. Update/confirm FHIR mappings for the various fields. We perhaps might want to limit this to the highest priority / lowest lift fields (i.e., adding Patient's city would be trivially easy, but probably doesn't add tremendous value over any
  2. Create a new ecr_test.json with the new fields that we would to see. To do that with orchestration, we should just have to update the reference here: https://github.com/CDCgov/phdi/blob/main/containers/orchestration/app/default_configs/test_config.json#L22
  3. Test and confirm that the new data is coming through while testing locally.
  4. Update ecr.json with any of the new fields needed post-MVP.
robertandremitchell commented 7 months ago

pushed a PR update to review as a team. My thoughts:

ecr_with_metadata.json could be a way that we marry the frontend and backend by being able to dynamically add new fields. for example, in the mockup designed by Ryan, we do not actually yet have all those fields mapped. In consultation with Dan, not all of these were mapped in message-parser; some do appear doable, as the PR shows, but others may be trickier / may in fact be multiple fields (name, address fields, for example).

robertandremitchell commented 7 months ago

The updates to ecr.json are a bit more fleshed out @jankimo . I think we will need to decide a few things:

  1. Whether we want additional fields as a must-have (in which case, I may need to work with other DIBBs members on building out test data to confirm successful implementation)
  2. the metadata piece. The work on mapping fields to look nice in HTML may be better taken up on the HTML ticket, will add more detail there.

Happy to go over point-1 today, lmk.