1. 360x Overall Flow and Interactions Primary goals are to: Standardize the type of data exchanged and how the data is transported. Provide transparency to progress and/or gaps in care until the loop is closed Design a process with a low bar of entry for implementations Add value to clinicians and overall clinical workflows Focus is placed on the transport and data exchanged Referral transparency will be inferred by the payload content (no explicit status) to indicate various checkpoints throughout the referral lifecycle.

2. Referral Workflow Review Referral Initiator Referral Recipient Referral Request Data: Patient, Referral Identifier, Priority, Reason, etc. Documentation: Referral Note Referral Request Response (Accept/Decline) Data: Patient, Referral Identifier, Status Documentation: None required Referral Scheduled Notification (Optional) Data: Patient, Referral Identifier, Date/time of appointment, Location, Provider Documentation: None required Referral No Show Notification (Optional) Data: Patient, Referral Identifier, Status Documentation: None required Referral Findings (Close the Loop) Data: Patient, Referral Identifier, Status Documentation: Consult Note

3. Referral Request Data: Patient Identifier and demographics Referral Identifier Priority Referral Note Code (LOINC: 57133-1) Reason for Referral Should we send this as standardized structured content? How can we support clarity? If reasons are not sufficient, what else is necessary to resolve concerns? Order Information Documentation: Summary clinical data (C-CDA) Should this be required? Are all sections appropriate? How can we prevent too much data vs. too little?

4. Referral Request Response (Accept/Decline) Data: Patient Identifier Referral Identifier Order Status Ability to send codified reason if declined Documentation: None

5. Referral Scheduled Notification (Optional) Data: Patient Identifier Referral Identifier Date/time of appointment Appointment Location Assigned Provider Documentation: None.

6. Referral No Show Notification (Optional) Data: Patient Identifier Referral Identifier Date/time of appointment Appointment Location Assigned Provider Documentation: None.

7. Referral Findings (Close the Loop) Data: Patient Identifier and demographics Referral Identifier Documentation: Consult Note (C-CDA) Any other additional documentation?

8. Potential Exception Flows Referral Cancellation Referral Initiator would send a cancellation request Referral Recipient would reply with a cancellation confirmation Referral Patient Seen Notification Provides a checkpoint noting the desired care was provided, but the results are delayed and will be provided at a later date. Referral Interim Consultation Note In the case of chronic treatment or resolutions that require multiple visits, interim “progress” may be desired instead of one Referral Findings (Close the Loop) result.

9. Other Questions Can a detailed description of the current AMA implementation be provided? What are the strengths of the current approach? What are the opportunities for improvement? What is the overall workflow for a typical referral? What content is exchanged throughout the workflow? What are the transport mechanisms used to send/receive referrals? What are the metrics being captured and analyzed? What additional metrics are desired/necessary to achieve additional improvement? What are the timelines/expectations for piloting?

10. 360x Workflow Specific Questions Is there a need to support multiple recipients? Should the C-CDA be required to initiate a referral request? If not, what supplemental documentation is necessary to reduce redundancy concerns? ???