We are seeing custom FHIR implementations doing a lot of work to get blank fields in that EHR vendors have implemented, that we are treating as 'always present'. This means that a future site implementing FHIR from scratch may run into similiar issues.
Creating a mock ndjson set that we could run through the ETL that contained some defined set of US Core mandatory fields for a set of selected FHIR resources would allow us to test the worst case - though it would introduce a :lot: of error handling that would slow down library build time, and would require deciding what the right set of profiles to check for in the construction of said data set, considering profile subsets that may not be present, like smoking status.
We are seeing custom FHIR implementations doing a lot of work to get blank fields in that EHR vendors have implemented, that we are treating as 'always present'. This means that a future site implementing FHIR from scratch may run into similiar issues.
Creating a mock ndjson set that we could run through the ETL that contained some defined set of US Core mandatory fields for a set of selected FHIR resources would allow us to test the worst case - though it would introduce a :lot: of error handling that would slow down library build time, and would require deciding what the right set of profiles to check for in the construction of said data set, considering profile subsets that may not be present, like smoking status.