BUG: Encounter Type should use <originalText> over <displayName>

[angelathe]

Description

In the example eCRs below, the Encounter Type shows as Ambulatory in the eCR Viewer, but displays as Office Visit in the eICR HTML.

This is because the displayName vs. originalText values of an encompassing encounter name are different values. "Ambulatory" comes from displayName, but "Office Visit" comes from original Text. The eCR Viewer chooses to display the displayName, but the HTML view uses the original Text.

For this ticket, please fix the FHIR conversion so that it prioritizes pulling the encounter type value from <originalText>, and if that doesn't exist, then to pull the information from <displayName>.

IMPORTANT: Please confirm this with Emma/Robert Mitchell/Brady Fausett/etc. first. Making the change above would require changing the conditional order in DataType/_Coding.liquid, and would therefore affect other resources that use this Coding data type.

Steps to reproduce

Example eCRs:

• 0aa7a9c2-87e4-4115-876e-b0253bb8dabf: Incorrectly shows Encounter Type as "Ambulatory"
• 4aca74f4-c3b7-49ce-a437-1c8594451926: eCR viewer shows encounter type ambulatory, but in the HTML it is Office Visit
• 5ff5928a-6c29-4a0c-bbe5-c96484bbd22c: Encounter type shows as Ambulatory in eCR viewer, but Office Visit in eICR.
• 6a6bcd7d-7bad-48f6-9e0b-39a4ec9e063e: Encounter type shows as Ambulatory in eCR viewer, but Office Visit in eICR.
• 8fd139db-e099-4d34-90ad-3c3e70d8704a: Encounter type shows as Ambulatory in eCR viewer, but Office Visit in eICR.
• TN_sample eCR6: The "orginalText" "Office Visit" is not displayed

Relevant files:

• Resource/_Encounter.liquid
• DataType/_Coding.liquid

Expected Result

The encounter type displayed in the eCR viewer should match the information displayed in the eICR HTML.

Actual result

Example from 4aca74f4-c3b7-49ce-a437-1c8594451926:

Priority

Provide an estimate for level of impact the bug has today by placing an X in the applicable bracket

Priority

• Low priority The bug does not have to be fixed immediately. High and medium priority bugs should be addressed first.
• Medium priority Typically, medium-priority bugs do not affect customers directly and therefore can be fixed in the normal course of testing and development.
• High priority High priority bugs must be addressed immediately. They often affect the app’s functionality and impact customers and their user experience. They must take priority.

Notes

FHIR conversion would be required for this ticket.