Page tree
Skip to end of metadata
Go to start of metadata



The main goal of this page is to clarify the Emergency Workflow. It will try to match the epSOS Specifications with the current implementation of OpenNCP, raising any faulty situations.

Table of contents:


1. Emergency workflow accordint to epSOS specifications

In this piece of the full PS workflow we can understand the following:

1HCP confirms that he checked the correctness of patient's ID details (Port-B)YESWith the selected option the HCP should then choose if it is an emergency case or not. We will proceed to follow the diagram as if it was one.
2Emergency case (button to confirm or deny)YESWith the selected option the system should send a request to the Patient's country right away, avoiding ask for previous consent. It is up to Country-A to provide or not the information, based on Emergency situation policy.


The next steps will depend on the Country-A Emergency situation policy. But the important part that is taken from the specs is the folllowing:

  1. The value XSPA Purpose of Use of the TRC (Treatment Relationship Confirmation) Assertion should be EMERGENCY;
  2. There should be produced an Audit Message stating the occurrence;

2. OpenNCP implementation

2.1. Portal Implementation

In the current Gnomon Portal implementation you have to select both the "Purpose of Use" and the "Previous Consent confirmation" options in order to proceed.

With this situation you cannot chose "EMERGENCY" and then go straight to the document search result, as the epSOS specifications state.

You can see that in the following picture:

2.1.1. Portuguese modified compliant version

In the Portuguese portal modified version we adapted the workflow to be more aligned with the specs. It has the following behaviour:

  1. Select the "document search" for the chosen patient;
  2. Select if it is an EMERGENCY or NOT EMERGENCY situation;
  3. If it is an EMERGENCY you are transported imediatly to document search result (depending, of course, on Country A decision);
  4. if it is NOT AN EMERGENCY you must specify if the patient has given previous consent. The next workflow will depend on the selected option;

This steps can be explained by the following animated picture:

This modification was achieved mainly by changing the default confirmation page (viewPatientConfirmationForDocuments.xhtml), that now contains the following code:

<!DOCTYPE html PUBLIC "-W3CDTD XHTML 1.0 TransitionalEN" "">
<html xmlns=""
            <p:panel header="#{translationBean.report_summary}">
                                    value="#{translationBean.patient_data_givenname}" /></b></td>
                        <td><h:outputText value="#{}" /></td>
                                    value="#{translationBean.patient_data_surname}" /></b></td>
                        <td><h:outputText value="#{myBean.selectedPatient.familyName}" /></td>
                                    value="#{translationBean.patient_data_street_address}" /></b></td>
                        <td><h:outputText value="#{myBean.selectedPatient.address}" /></td>
                                    value="#{translationBean.patient_data_code}" /></b></td>
                        <td><h:outputText value="#{myBean.selectedPatient.postalCode}" /></td>
                                    value="#{translationBean.patient_data_city}" /></b></td>
                        <td><h:outputText value="#{}" /></td>
                                    value="#{translationBean.patient_data_country}" /></b></td>
                        <td><h:outputText value="#{}" /></td>
                header="Confirmar com o doente (acesso aos seus dados clínicos):" id="confirmationPanel">
                <p:outputPanel id="customPanel">
                    <td><b><h:outputText value="Atendimento:" /></b></td>
                    <p:selectOneRadio id="customRadio"
                                      value="#{confirmationBean.purposeOfUse}" layout="custom">
                        <f:selectItem itemLabel="&nbsp;&nbsp;EMERGENTE (não é possível obter o consentimento)"
                                      itemValue="EMERGENCY" />                                                                                       
                        <f:selectItem itemLabel="&nbsp;&nbsp;NÃO URGENTE"
                                      itemValue="TREATMENT" />
                        <p:ajax update="confirmationPanel"/>
                    <h:panelGrid columns="2">
                        <p:radioButton id="opt2" for="customRadio" itemIndex="0" />
                        <h:outputLabel for="opt2" value="&nbsp;&nbsp;EMERGENTE (não é possível obter o consentimento)" />
                        <p:radioButton id="opt1" for="customRadio" itemIndex="1" />
                        <h:outputLabel for="opt1" value="&nbsp;&nbsp;NÃO URGENTE" />
                <p:outputPanel rendered="#{confirmationBean.purposeOfUse=='TREATMENT'}" id="customPanel2">      
                                value="Deu consentimento prévio?" /></b></td>
                    <p:selectOneRadio id="customRadio2"
                                      value="#{confirmationBean.confirm}" layout="custom">
                        <f:selectItem itemLabel="Yes" itemValue="Yes" />
                        <f:selectItem itemLabel="No" itemValue="No" />
                    <h:panelGrid columns="2">
                        <p:radioButton id="opt11" for="customRadio2" itemIndex="0" />
                        <h:outputLabel for="opt11" value="&nbsp;&nbsp;Sim" />
                        <p:radioButton id="opt22" for="customRadio2" itemIndex="1" />
                        <h:outputLabel for="opt22" value="&nbsp;&nbsp;Não" />
                <p:commandButton id="submitButton" 
                    <p:resetInput target="confirmationPanel" />
                    <f:setPropertyActionListener value="#{confirmationBean.purposeOfUse}"
                                                 target="#{myBean.purposeOfUseForPS}" />
                    <f:setPropertyActionListener value="#{confirmationBean.confirm}"
                                                 target="#{myBean.previousConsent}" />
                    <f:setPropertyActionListener value="null"
                                                 target="#{confirmationBean.purposeOfUse}" />
                    <f:setPropertyActionListener value="null"
                                                 target="#{confirmationBean.confirm}" />
                <p:commandButton id="cancelButton" value="Cancelar" ajax="false"
                                 action="/view1.xhtml?javax.portlet.faces.PortletMode=view&amp;javax.portlet.faces.WindowState=normal" />

Please give importance to:

<p:selectOneRadio id="customRadio" value="#{confirmationBean.purposeOfUse}" layout="custom">
	<f:selectItem itemLabel="&nbsp;&nbsp;EMERGENTE (não é possível obter o consentimento)" itemValue="EMERGENCY" />                                                                                       
    <f:selectItem itemLabel="&nbsp;&nbsp;NÃO URGENTE" itemValue="TREATMENT" />
	<p:ajax update="confirmationPanel"/>

That will trigger the "hide and show" of the question that asks for the previous consent, together with the following tag:

<p:outputPanel rendered="#{confirmationBean.purposeOfUse=='TREATMENT'}" id="customPanel2">

2.2. Assertion type

The current implementation will produce a Treatment Relationship Confirmation (TRC) assertion with a specific XSPA Purpose of Use value, based on the selected purpose of use (EMERGENCY or NOT EMERGENCY <=> TREATMENT) 

<saml2:Attribute FriendlyName="XSPA Purpose Of Use" Name="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
	<saml2:AttributeValue xmlns:xsi="" xsi:type="xs:string">EMERGENCY</saml2:AttributeValue>

According to specifications, this action is correct and no action is required.

2.3. Audit message

In the current implementation there is no Audit Message when the Emergency workflow is triggered;

  The non-functional requirement NFR06 - Audit Trail, present int the document D3.2.2 "Final definition of functional service requirements" states the following:

 "Extraordinary and/or emergency accesses must be specially marked in order to facilitate the local management of those."

Therefore an extra audit message needs to be triggered in this particular situations. The main issue is that there is not any audit message specified for this particular situation.

3. Actions to be taken in OpenNCP

TaskRelated IssuesComments
Adjust Portal implementation to match epSOS specs GPB-19 - Getting issue details... STATUS

The workflow of the portal has been adjusted to allow the specific consent final question. (To be asked to the patient).

Specify Emergency triggered Audit MessageNothing to doAlready supported by the security header, present in the produced assertions.
Add functionality to send the specified audit messageNothing to doAlready supported by the produced assertions.


4. References


  1. Awesome!!!

    Great job Marcelo Fonseca

  2. I agree with this implementation. You can commit it in the openncp portal repository. Licínio kustra Mano [PT] I can't find the issue in the epsos support systerm. Can you place it here?

    As for

    • Adjust Portal implementation to match epSOS specs;
    • Specify Emergency triggered Audit Message;
    • Add functionality to send the specified audit message;

    the 2nd and the 3rd are already handled by portal with trca assertion that is beeing send to the server


  3. Dear Marcello,


    please excuse me growing a little tired with the topic at hand. I am providing the very input that you and the OpenNCP team need since almost a year. The last communication I had was not three weeks ago in which I clarified once more what is there, how it can be used, and what needs to be done. Opening yet another ticket, another Wiki page, and another e-mail conversation is not very helpful.


    Please let me elaborate one more time. I have taken the liberty to hijack a random audit trail from Gazelle for demonstration purposes:


    Both, he “old” specification D3.4.2v1.00 as well as WP3.A.3, and the respective binding are normatively specifying in “Audit Trail Data for Non-Repudiation” to mandatorily capture the “Full security header of the response message as a type-value pair acc. to [RFC 3881]. As a type qualifier “securityheader” MUST be used. The value MUST contain the base64 encoded security header” as “ParticipantObjectID” of both, the Request and Response message. This results in a Auditable Event with an element like this:


    <ParticipantObjectIdentification ParticipantObjectID="urn:uuid:96f9857a-4038-48f1-9a5c-661f8d004c1d" ParticipantObjectTypeCode="4">

         <ParticipantObjectIDTypeCode code="req" codeSystemName="epSOS Msg" displayName="Request Message"/>

         <ParticipantObjectDetail type="securityheader" value="V6QVJNQThHRFNzR0F [SHORTENED FOR READABIITY] gpEUVVBQTRJQkFRQ2JXZ=="/>



    The element type securityheader contains the full security context of the message and as such it also contains the transactional status of a potential emergency access. Please note that the security header is base64 encoded but after running it through a decoder, the following information comes to light (shortened and emphasized for better readability):


    </saml2:Attribute><saml2:Attribute FriendlyName="XSPA Purpose Of Use" Name="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

           <saml2:AttributeValue xmlns:xsi="" xsi:type="xs:string">TREATMENT</saml2:AttributeValue>



    The information requested by the OpenNCP team is already included in all emergency-respective transactions and their specific Audits. However, since now the Tiani NCP was raising the “red flag” through their Policy Management and not through the Audit Trail Viewer component from Gnomon. The latter is, as far as I know, merely displaying the security header still encoded as base64 and may potentially have that information overlooked in result. I have already recommended several times to adapt the viewer to make this information easily accessible.


    In summary, we do NOT need yet another Audit message or any adaption. All information required is there and readily available for implementing the “red flag”. It just needs to be properly processed.



    All the best,



  4. Dear Soeren,

    Thank you very much for your precious contribution.

    As far as i understood from your comments, the OpenNCP (and Tiani) already supports the inclusion of a flag stating the Emergency Scenario. And that is through the usage of the "XSPA Purpose Of Use" attribute, present in the security header. The only improvement that could be implemented is to give more visibility to that specific field, present in the assertion.

    My first impression is that an additional audit message, triggered at the Emergency selection moment was missing - and that was a wrong impression.

    Also, regarding your first words, the main purpose of this page was to clarify that scenario in the OpenNCP and to show the Portuguese approach, regarding the Portal. The only blurred part was the Audit Message, and that was correctly clarified by you.

    I did not create any more ticket besides the one already existent in Central Services (#315), created by Marcello Melgara. I've only added this page to act as a complement. And it seems that the blurred Audit part was not being understood by anyone else, due to the lack of comments, bringing higher importance to this page and your contribution.

    Once again, thank you very much for your help.

  5. Hi Marcelo, my apologies for not being aware of the name issue. I was directing my concern at Marcello Melgara and it did come across somewhat rude. This was unintentional. I was merely surprised about this topic frequently popping up since years and with quite some insistence. The OpenNCP team has one of the original developers, Kostas, on board to whom I have communicated the provisions of the Audit Trail in great detail since 2010 in order to have him ready for implementing that very component in Open Source. I have also had detailed discussions with Konstantin, Mustafa, and Steen over the years with many invaluable contributions to make the specifications better and more stable.

    Please also note that WP3.A has also been "ordered" to safeguard the backwards compatibility of the original services and as such we're in a difficult position: making sure that PN's like France can go on without any alterations without standing in the way of the OpenNCP prospering through new functionality. Naturally, I am getting very careful whenever something new is determined as "required" and usually insist on a comprehensive evaluation. This is not to slow you guys down in any way but an attempt to keep the specifications integrity over time. We already have a project of greatly diverging speeds - some stalling, some conservative, others motivated to progress beyond "epSOS" - but the principle of epSOS is set to accommodate everyone.