Second Opinion

Rofim enables complete interoperability of the second opinion request lifecycle with the HIS (Hospital Information System). With a second opinion request, the patient submits a request directly on the Rofim platform, addressed to a second physician of the facility.

Before being made available to the facility, the request must be validated by a user of the facility (typically a medical secretary), who checks both the documents provided by the patient and the second opinion request itself.

The logic is very similar to the one described for Incoming TE/Referrals, except that there is no billing flow. Three interoperability flows must be implemented:

Retrieving second opinion requests (SIU S12)
Updating the patient identity and IPP (SIU S14)
Retrieving the patient's documents (MDM or ORU)

The logic is as follows:

The patient submits a second opinion request on the Rofim platform.
A user of the facility (medical secretary) validates the documents provided by the patient as well as the second opinion request.
Once validated, the request is made available as an SIU S12 message, which can be retrieved by the facility.
The facility matches the patient with a patient known to the hospital, or creates a new patient.
The facility sends back an appointment update message (SIU S14) to update the patient identity in Rofim and convey the patient's IPP.
The patient's documents are transmitted through an HL7 MDM or ORU message, as a base64-encoded attachment.

Retrieving Second Opinion Requests

This flow allows retrieving validated second opinion requests via an SIU S12 message.

Data	Value
Supported format	`HL7 2.5`
Supported messages (outgoing)	`SIU 12`
Message type	`GET`
API link	base_url/dsa/siu

Important Data

Data	Field	Format	Required	Comment
Unique identifier of the second opinion request (placer)	`SCH.1.1`	String	Yes	Unique ID of the second opinion request in Rofim
Unique identifier of the second opinion request (filler)	`SCH.2.1`	String	Yes	Same value as `SCH.1.1`. To be used in subsequent `S14` messages
Facility request identifier	`SCH.7.2`	String	Yes	Identifier of the second opinion request on the facility side
Validation date/time	`SCH.11.4`	DTM (`YYYYMMDDHHMMSS`)	Yes	Date and time the request was validated by the facility user
Request status	`SCH.25.1`	String	Yes	Status of the second opinion request in Rofim
Start date/time	`AIS.4.1`	DTM (`YYYYMMDDHHMMSS`)	Yes	Same value as `SCH.11.4` (validation date/time)
Birth name (legal name)	`PID.5.1.1`	String	Yes	Patient last name. First repetition, with `PID.5.7` set to `L`
Given name	`PID.5.2`	String	Yes	Patient first name (first and second repetitions)
\|-- Name type code	`PID.5.7`	String	Yes	`L` (legal name) in the first repetition, `D` (usual name) in the second
Usual name	`PID.5.1.1`	String	No	Second repetition, with `PID.5.7` set to `D`. If no usual name is provided, the birth name is used
Date of birth	`PID.7.1`	DT (`YYYYMMDD`)	Yes
Administrative sex	`PID.8`	String	Yes	`M` or `F`
Street address	`PID.11.1.1`	String	No
City	`PID.11.3`	String	No
Zip code	`PID.11.5`	String	No
Country	`PID.11.6`	String	No
Phone number	`PID.13.1`	String	No	Repetition with `PID.13.2` set to `PRN` and `PID.13.3` set to `PH`
Email address	`PID.13.4`	String	No	Separate repetition, with `PID.13.2` set to `NET` and `PID.13.3` set to `Internet`
Social security number	`PID.19`	String	No	Patient NIR
Birth place	`PID.23`	String	No	City of birth
Stay identifier	`PV1.19.1`	String	No	IEP or stay identifier
\|-- Assigning authority (OID)	`PV1.19.4.2`	String	No	OID of the authority that assigned the stay identifier

Message Examples

<?xml version="1.0" encoding="UTF-8"?>
<message>
    <content>TVNIfF5+XCZ8Uk9GSU18Uk9GSU18fF4zMTA3ODMwNDh8MjAyNjEwMDkxMjQzMzN8fFNJVV5TMTJe
U0lVX1MxMnwxNzM3Nzc0fFB8Mi41fHx8fHxGUkF8VVRGLTh8RlJBDVNDSHw2YWI1MGM1MjA4M2Fj
N2ZhZDViOGI5OTF8NmFiNTBjNTIwODNhYzdmYWQ1YjhiOTkxfHx8fHxeMjYtMDAwMnx8fHxeXl4y
MDI2MDkyNDExNDQ0N3x8fHx8fHx8fHx8fHx8dmFsaWRhdGVkDVBJRHx8fHx8REVaT1JET15NYXJj
Xl5eXl5MfkRFWk9SRE9eTWFyY15eXl5eRHx8MTk4OTEyMTB8TXx8fF5eTWFyc2VpbGxlXl4xMzAw
Nl5GUnx8Xl5eZXJ3YW4rY3VyaWVwcC5tYXJjQHJvZmltLmRvY3Rvcnx8fHx8fE5DDUFJU3x8fHwy
MDI2MDkyNDExNDQ0Nw==</content>
    <content>TVNIfF5+XCZ8Uk9GSU18Uk9GSU18fF4zMTA3ODMwNDh8MjAyNjEwMDkxMjQzMzN8fFNJVV5TMTJe
U0lVX1MxMnwxNzM3Nzc1fFB8Mi41fHx8fHxGUkF8VVRGLTh8RlJBDVNDSHw2YWI1MTc2YTdjOTY1
MDVhZjYwN2FmZGF8NmFiNTE3NmE3Yzk2NTA1YWY2MDdhZmRhfHx8fHxeMjYtMDAwNHx8fHxeXl4y
MDI2MDkyNDEyMjkwNHx8fHx8fHx8fHx8fHx8dmFsaWRhdGVkDVBJRHx8fHx8UUFeQ3VyaWVeXl5e
Xkx+UUFeQ3VyaWVeXl5eXkR8fDE5NzEwNjE2fE18fHxeXlBhcmlzXl43NTAwMF5GUnx8Xl5ebGlz
YXJvZmltK2N1cmllcGF0aWVudDJAZ21haWwuY29tfHx8fHx8TkMNQUlTfHx8fDIwMjYwOTI0MTIy
OTA0</content>
    <content>TVNIfF5+XCZ8Uk9GSU18Uk9GSU18fF4zMTA3ODMwNDh8MjAyNjEwMDkxMjQzMzN8fFNJVV5TMTJe
U0lVX1MxMnwxNzM3Nzc2fFB8Mi41fHx8fHxGUkF8VVRGLTh8RlJBDVNDSHw2YWI1MTQ5NTA4M2Fj
N2ZhZDViOTIyMWN8NmFiNTE0OTUwODNhYzdmYWQ1YjkyMjFjfHx8fHxeMjYtMDAwM3x8fHxeXl4y
MDI2MDkyNDEyNDcyM3x8fHx8fHx8fHx8fHx8dmFsaWRhdGVkDVBJRHx8fHx8QU5HRV5IZXJ2w6le
Xl5eXkx+QU5HRV5IZXJ2w6leXl5eXkR8fDE5OTkxMDEwfE18fHxeXk1hcnNlaWxsZV5eMTMwMDZe
Qkp8fF5eXmFuZ2UuaGVydmVAcm9maW0uZG9jdG9yfHx8fHx8TkMNQUlTfHx8fDIwMjYwOTI0MTI0
NzIz</content>
    <content>TVNIfF5+XCZ8Uk9GSU18Uk9GSU18fF4zMTA3ODMwNDh8MjAyNjEwMDkxMjQzMzN8fFNJVV5TMTJe
U0lVX1MxMnwxNzM3Nzc3fFB8Mi41fHx8fHxGUkF8VVRGLTh8RlJBDVNDSHw2YWI1NDhjOTNlNmVi
YTgzNTg5ZTk2ZDl8NmFiNTQ4YzkzZTZlYmE4MzU4OWU5NmQ5fHx8fHxeMjYtMDAwNnx8fHxeXl4y
MDI2MDkyNTE1MDM1OXx8fHx8fHx8fHx8fHx8dmFsaWRhdGVkDVBJRHx8fHx8TUFDSElOXnRydWNe
Xl5eXkx+TUFDSElORV50cnVjXl5eXl5EfHwxOTk5MDkwOXxGfHx8Xl50Xl50XkZSfHxeXl5tYWNo
aW50cnVjQHlvcG1haWwuY29tfHx8fHx8TkMNQUlTfHx8fDIwMjYwOTI1MTUwMzU5</content>
</message>

MSH|^~\&|ROFIM|ROFIM||^310783048|20261009124333||SIU^S12^SIU_S12|1737777|P|2.5|||||FRA|UTF-8|FRA
SCH|6ab548c93e6eba83589e96d9|6ab548c93e6eba83589e96d9|||||^26-0006||||^^^20260925150359||||||||||||||validated
PID|||||MACHIN^truc^^^^^L~MACHINE^truc^^^^^D||19990909|F|||^^t^^t^FR||^^^[email protected]||||||NC
AIS||||20260925150359

Updating Patient Identity and IPP

Once the facility has matched or created the patient, it must send an SIU S14 message to update the patient identity in Rofim and convey the patient's IPP.

Data	Value
Supported format	`HL7 2.5`
Supported messages (incoming)	`SIU 14`
Message type	`POST`
API link	base_url/dsa/siu14

Important Data

Data	Field	Format	Required	Comment
Unique identifier of the second opinion request	`SCH.1.1` / `SCH.2.1`	String	Yes	Unique Rofim ID of the second opinion request, as sent by Rofim in the same fields of the `S12` message
Patient identifier (IPP)	`PID.3.1`	String	Yes	Patient IPP generated by the facility
\|-- Assigning Authority	`PID.3.4`	String	Recommended	Assigning authority of the IPP
\|-- ID Type	`PID.3.5`	String	Recommended	Set to `PI`
Stay identifier (IEP)	`PV1.19.1`	String	No	IEP or stay identifier generated by the facility
\|-- Assigning Authority	`PV1.19.4`	String	Recommended	Assigning authority of the IEP
\|-- ID Type	`PV1.19.5`	String	Recommended	Set to `VN`

Message Examples

MSH|^~\&|ROFIM|ROFIM||^310783048|20261009124333||SIU^S14^SIU_S14|1737777|P|2.5|||||FRA|UTF-8|FRA
SCH|6ab548c93e6eba83589e96d9|6ab548c93e6eba83589e96d9|||||^26-0006||||^^^20260925150359||||||||||||||validated
PID|||1234567^^^CURIE^PI||MACHIN^truc^^^^^L~MACHINE^truc^^^^^D||19990909|F|||^^t^^t^FR||^^^[email protected]||||||NC
PV1|||||||||||||||||||343434^^^CURIE^VN
AIS||||20260925150359

Retrieving Patient Documents

This flow allows retrieving the documents provided by the patient with the second opinion request. Each document is transmitted as a base64-encoded attachment in an HL7 MDM or ORU message.

Data	Value
Supported format	`HL7 2.5`
Supported messages (outgoing)	`MDM or ORU`
Message type	`GET`
API link	base_url/dsa/cr

Important Data

Data	Field	Format	Required	Comment
TODO	TODO	TODO	TODO	TODO

Message Examples

TODO

TODO