Short Description

Bidirectional Services e-Referrals (BSeR)

Long Description

Track will focus on the exchange of electronic referrals between a healthcare organization and an extra-clinical entity following the BSeR framework (ie using ServiceRequest and Task) 


Test an Implementation Guide

Related Tracks?

Call for participants

EHRs/HIEs (clinical data sources); extra-clinical referral recipients

Track Prerequisites

Knowledge of the BSeR Implementation Guide (current build):

Documentation: The BSeR Implementation Guide provides several key ares of documentation which can aid in testing. One of the most relevant for Connect-a-thon testing is the Workflow Management page found at, which includes a State Transition Table and State Machine Diagram. The State Transition Table will be referenced in this document by TID (Transition ID) to draw a line between the state transitions of the workflow and tasks that must be carried out in workflow testing.

Ability to create and send a BSeR referral Bundle or ability to receive a BSeR referral Bundle as specified in the BSeR IG

Track Lead(s)

Sarah Gaunt

Track Lead Email(s)

Specification Information

Zulip stream

Track Kick off Call

Slides: Bidirectional Services eReferrals Connectathon Track Kick-Off.pptx

Monday April 10, 2023 2-3pm ET

Microsoft Teams meeting

Join on your computer, mobile app or room device

Click here to join the meeting

Meeting ID: 242 019 371 530
Passcode: FpnWSp

Download Teams | Join on the web

Or call in (audio only)

+1 208-996-1659,,900748323#   United States, Boise

Phone Conference ID: 900 748 323#

Find a local number | Reset PIN 



  • 9am Kick-off
      • Welcome and introductions
      • Goals etc.
      • IG Updates/Version
  • 10am Testing/Setup
  • 11am Breakout (Magazine)
    • Issues
    • detailed updates to the IG
    • round table updates/discussion
  • 12 Lunch
  • 1pm Optional Breakout Referral Harmonization           


  • 9am Re-cap of Saturday - where we got to, issues etc
  • 9:30 am Testing
  • 2pm Results etc. to Sarah for compilation in the report-out document

Possible Discussion Topics:

    Task and ServiceRequest (harmonization etc.)
    State machine/transactions
    Extensibility models

Testing Scenario:


                P1: Clinical Service Provider – referral initiator

                P2: Extra-clinical Service Provider – referral recipient

Scenario 1: BSeR FHIR IG Validation

P1 generates referral request and validates using the HL7 validator

Roles generates referral feedback and validates using the HL7 validator

It’s required for P1 to pass the validation to proceed to the next scenario in this Connectathon. It’s optional for P2 if P2 is not ready to produce the feedback report. It is however required for P2 to consume and process the validated referral request.

Scenario 2:   The referral initiator initiates the referral task by sending the referral service request to the referral recipient. The initiator is related to an organization and a service delivery location.

P1:         Referral Request creation & send

P2:         Register practitioner/organization (with an endpoint) to P1 referral testing system. P1 should work with P2 and have them registered before the connectathon

Step 1: Creation of the referral request package

Success Criteria:   Confirm successful response message (or ACK) and screenshot of recipient system that shows the received message or content.

Bonus point:        Referral request message Bundle include Patient consent; referral recipient handles this consent to initiate a Referred Patient Intake workflow culminating in a Service Delivery Plan creation

Scenario 3: The referral recipient consumes the received referral request package and parse the package and extract clinical information in the package. The clinical information is available in the referral request document bundle -

P2: Receive and consume the referral request packet

Step 1: P2 provides the messaging endpoint (<system URL>/$process-message).

Step 2: P2 receives the referral request package

  • Sends the ACK to referral recipient in the (synchronous) messaging.
  • Consumes the data and confirms that it has enough information to develop service plan.

Success Criteria:   Sent ACK to the initiator (where the referral request is coming from) and screenshot of initiator system that shows the messaging was successful. P2 shows the patient data for the service plan.

Scenario 4: The referral recipient (assuming the service plan was established, and the patient is following the service plan) creates referral feedback bundle(s) and send the feedback to the referral initiator. In real world, the feedback will be sent periodically over time. For the connectathon, it will be one time (or more if P2 is willing to test).

P2: Creation of Service Delivery Feedback Report (iteratively if possible) culminating in Referral Activity status P2 sends the feedback report to the referral initiator and receive ACK message.

Step 1: P2 creates referral feedback package and sends it to referral initiator using a message bundle

  • Referral initiator endpoint should be available from the initial referral request.
  • The feedback message should be sent to <referral initiator URL>/$process-message

Step 2: P2 may repeat the feedback messaging. Proper status indication and resource bundling should be performed if this is repeating

Step 3:  P1 should send ACK back to P2 synchronously and updates the referral status.

Success Criteria:   ACK is received by P2 from P1. P1 shows the feedback report in the P1 system.