Teleexpertise/Referrals

Rofim enables complete interoperability of the TE/referral lifecycle with the HIS (Hospital Information System) or Practice Management Software, whether your organization is the requesting or requested party. From a workflow perspective, it's possible to distinguish two types of TE/referrals:

• Outgoing TE/Referrals: When TE/referrals are performed within the facility and sent externally.
• Incoming TE/Referrals: When the facility is addressed from outside (by the community or by another facility, for example).

TE/Referrals are "conveyed" through SIU flows, which allows transporting the patient's identity, as well as a specific reason for the TE/referral and the necessary IPP (Patient Identifier) and IEP (Stay Identifier) for billing and document archiving workflows.

The final objective of implementing these flows is:

• automation of TE/referral billing
• automation of archiving TE/referral reports in patient records

Outgoing TE/Referrals

In the context of outgoing TE/referrals, implementing an IMS flow will help avoid double entry of patient information and find patients via their IPP.

The objective of the following appointment flows (S12 and S14) will be to retrieve the IEP of the stay concerning the TE/referral. The logic is as follows:

• After the TE/referral is created by a physician from the facility, an S12 message is sent to the facility. This message serves as a 'vehicle' for the TE/referral (via a specific reason). It contains the patient concerned by the TE/referral.
• The facility then generates a stay number / venue ID.
• The facility sends back an appointment update message (S14) in which the stay/venue is present.

Retrieving Created TE/Referrals

This flow allows retrieving TE/referrals created via an S12 message for the purpose of the facility generating an IEP.

TE/Referrals are provided in an XML file containing all SIU 12 messages encoded in base 64. The format of the XML file is described below:

<message>
  <content>SIU12 N°1 encoded in B64</content>
  <content>SIU12 N°2 encoded in B64</content>
  <content>SIU12 N°3 encoded in B64</content>
  ...
</message>

Important Data

Message Examples

<?xml version="1.0" encoding="UTF-8"?>
<message>
  <content>

  </content>
  <content>

  </content>
</message>

<?xml version="1.0" encoding="UTF-8"?>
<message/>

Updating Patient ID (IPP) and Venue ID (IEP)

Following the generation of the Venue ID IEP and/or Patient IDIPP, the facility must update the TE/referral via sending an S14 message.

Important Data

Fields not described in this section must conform to the definition provided in the patient / ims data flow.

Message Examples

Incoming TE/Referrals

The objective of the following appointment flows (S12 and S14) will be to retrieve the patient's IPP on the hospital side and the IEP of the stay concerning the TE/referral. The logic is as follows:

• After the TE/referral is closed (and the report is written) by a physician from the facility, an S12 message is sent to the facility. This message serves as a 'vehicle' for the TE/referral (via a specific reason). It contains the patient concerned by the TE/referral.
• The facility must then match the patient with a patient known to the hospital (via INS or identity management data) or create a temporary patient, the purpose of this creation being to enable billing of the TE/referral act.
• The facility then generates a stay number.
• The facility sends back an appointment update message (S14) in which the IPP and stay are present.

💡

Admissions Office and Patient Identity Management

During this step, patient identities will be injected into the HIS, it's important to involve the admissions office and patient identity management teams early on these topics that will impact patient creation processes.

Retrieving TE/Referrals Addressed to the Facility

This flow allows retrieving closed TE/referrals (i.e.: a report has been written by a physician from the facility) via an S12 message for the purpose of the facility generating an IPP and an IEP.

TE/Referrals are provided in an XML file containing all SIU 12 messages encoded in base 64. The format of the XML file is described below:

<message>
  <content>SIU12 N°1 encoded in B64</content>
  <content>SIU12 N°2 encoded in B64</content>
  <content>SIU12 N°3 encoded in B64</content>
  ...
</message>

Important Data

Message Examples

<?xml version="1.0" encoding="UTF-8"?>
<message>
  <content>

  </content>
  <content>

  </content>
</message>

<?xml version="1.0" encoding="UTF-8"?>
<message/>

Updating IPP and IEP

Once the facility has been able to create an identity for the patient, it's necessary to send an S14 message with the updated data important for billing:

• IPP
• IEP
• UF (Functional Unit)

The format and endpoint of this message is identical to that of the incoming TE/referral, and described here.

Retrieving TE/Referral Reports

Retrieving TE/referral reports is identical for incoming and outgoing TE/referrals. Thus, only one connector needs to be implemented. All available reports added since the last call are provided in the response to this interface.

Reports are provided in an XML file containing all HL7 messages encoded in base 64. The format of the XML file is described below:

<message>
  <content>HL7 ORU or MDM N°1 encoded in B64</content>
  <content>HL7 ORU or MDM N°2 encoded in B64</content>
  <content>HL7 ORU or MDM N°3 encoded in B64</content>
  ...
</message>

The MDM or ORU message contains the report in PDF encapsulated in base 64. The message also contains additional business data allowing easier file management on the Electronic Health Record side. This important data is described below.

Important Data

Message Example

<?xml version="1.0" encoding="UTF-8"?>
<message>
  <content>
   
  </content>
  <content>
    
  </content>
</message>

<?xml version="1.0" encoding="UTF-8"?>
<message/>

Billing

This interface allows retrieving performed acts ready to be billed. All new acts performed since the last call are returned by this interface.

Retrieving TE/referral billing files is identical for incoming and outgoing TE/referrals. Thus, only one connector needs to be implemented. Act coding will be different depending on the type of TE/referral:

• TE2 for incoming TE/referrals on which an opinion has been provided by a physician from the facility
• RQD for an outgoing TE/referral

❗️

Limit on the number of reimbursable TE/referrals

Regulations limit the number of reimbursements for a patient/requested physician pair to 4 per year. In this case, the act will be coded with this value: TE2_LIMIT_REACHED

<message>
  <content>HPRIMXML N°1 encoded in B64</content>
  <content>HPRIMXML N°2 encoded in B64</content>
  <content>HPRIMXML N°3 encoded in B64</content>
  ...
</message>

Important Data

🚧

TODO

Message Example

<?xml version="1.0" encoding="UTF-8"?>
<message>
  <content>
  </content>
  
  <content> 
  </content>
  
  <content>
  </content>
</message>

TODO

TODO

Patient Matching via INS

In the context of incoming TE/referrals, the ideal operation is to match the patient brought by the community to the hospital via qualified INS. This data will be present in the PID.3.1 field (with PID.3.4 set to ASIP-SANTE-INS). However, field experience shows the following issues:

• A low rate of qualified INS for community patients
• The presence of foreign patients
• The presence of patients without INS

It is therefore necessary to implement, on the facility side, a two-step matching process:

• Based on INS if it is present and qualified
• Based on strict identity management traits