Open emmastephenson opened 1 year ago
thoughts on making [https://app.zenhub.com/workspaces/dibbs-engineering-63f7aa3e1ecdbb0011edb299/issues/gh/cdcgov/phdi/191]([EPIC] Create an eCR database for LAC) a set of tickets under this epic? my understanding was that the primary reason for making the eCR database was to give a short term solution for provenance tracking (and also allow for analytics outside of IRIS) before implementing a specific FHIR provenance resource or some more scalable/sustainable solution
oops can't edit comments in Zenhub I have just learned, heres the same message with a not distracting URL:
thoughts on making [https://app.zenhub.com/workspaces/dibbs-engineering-63f7aa3e1ecdbb0011edb299/issues/gh/cdcgov/phdi/191](EPIC Create an eCR database for LAC) a set of tickets under this epic? my understanding was that the primary reason for making the eCR database was to give a short term solution for provenance tracking (and also allow for analytics outside of IRIS) before implementing a specific FHIR provenance resource or some more scalable/sustainable solution
i give up ¯_(ツ)_/¯
Why are we doing this?
The pipeline can accept multiple types of records (eLR, eCR, VXU, etc) but once these records are converted to FHIR, we don't have a way to link a specific FHIR resource to the message type it originated from. This is an issue if users want to perform analysis operations on all patients that came in on an eCR, for instance.
Action Requested
Add provenance tracking to the pipeline. (This is an epic; ticket breakdown to come.)
Acceptance Criteria
Given a specific FHIR resource like patient, I can identify the message type it originated from.