FAQ

Q: Can you refresh a token  ? 

A:

•  Web app: it is possible  → refresh token valid for 2 hours 
•  Mobile app: not possible 

→  http://doc.brusafe.be/display/MQE/Portal+api+security

Q: I get a HTTP 404  or 403 response when I try to access an endpoint on Brusafe+
A: This has most likely to do with your TLS certificate, that isn't trusted by Brusafe+ . Make sure you've followed the procedures to get your certificate trusted.

Q: In the SOAP-reponse, I get back the message 'A security error was encountered when verifying the message'
A: This has to do with your SAML token, that's isn't accepted by Brusafe+. There are several possibilties: the SAML token can be expired 2) You're using a production SAML token on Brusafe+ QA environment or vice versa 3) the SAML token isn't placed the right way in your request, like the snippet below. The SAML token must be placed in the SOAP Header, between wsse:Security-tags. Important is that the SAML assertion doesn't has spaces, newlines, carriages return etc. between the tags.

<s:Envelop>
<s:Header>
      <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
          <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="ID_7078eeb2-b405-4b38-a6df-266a52c483b0" IssueInstant="2017-04-14T12:25:23.166Z" Version="2.0">.....</saml:Assertion>
      </wsse:Security>   
      ....
</s:Header>
<s:Body>
      ....
</s:Body>
</s:Envelop>

Q: Developers working on the integration with Brusafe+ don't know if they have to use multipart or Base64 to embed the CDA in the XDS ?

A:

You should use the XOP to transfer the CDA to MTOM: 

XOP example:

______________________________________________________________________________

…

    <soapenv:Body>

        <xdsb:ProvideAndRegisterDocumentSetRequest xmlns:xdsb="urn:ihe:iti:xds-b:2007">

            <lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">

                <rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">

                    <rim:ExtrinsicObject id="Document01" mimeType="text/plain"/>

                </rim:RegistryObjectList>

            </lcm:SubmitObjectsRequest>

            <xdsb:Document id="Document01">

                <xop:Include href="cid:1.urn:uuid:AFBE87CB65FD88AC4B1220879854390@apache.org"

                    xmlns:xop="http://www.w3.org/2004/08/xop/include"/>

            </xdsb:Document>

        </xdsb:ProvideAndRegisterDocumentSetRequest>

    </soapenv:Body>

</soapenv:Envelope>

--MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348

Content-Type: text/plain

Content-Transfer-Encoding: binary

Content-ID: <1.urn:uuid:AFBE87CB65FD88AC4B1220879854390@apache.org>

This is my document.

It is great!

--MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348--

______________________________________________________________________________

It's indeed MTOM with XOP that must be used as used with the XDStarClient (see response at https://gazelle.ehealth.brussels/XDStarClient/messages/message.seam?id=355).

When you dig into the logs of EVS client and further on the response

When you further click on the ID 145 : Make sure you are using CTRL+U for the full view of the message

There is a passed document on the EVS client, however this should be rejected because base 64 has been used:

→ This issue will be solved in Gazelle so further confusions cannot be caused.

Q: Can you explain in simple words the difference between Saml , CDA en XDS ?

A:

Saml token: confirmation of a therapeutic relation between a healthcare provider that is sending information and the patient itself

 CDA: is the XML where the data is encoded

XDS:  A way of transporting and accessing the data on a standardized manner:

http://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing 
Cross-Enterprise Document Sharing (XDS) is focused on providing a standards-based specification for managing the sharing of documents between any healthcare enterprise, ranging from a private physician office to a clinic to an acute care in-patient facility and personal health record systems. This is managed through federated document repositories and a document registry to create a longitudinal record of information about a patient within a given clinical affinity domain. These are distinct entities with separate responsibilities:

• A Document Repository is responsible for storing documents in a transparent, secure, reliable and persistent manner and responding to document retrieval requests.
• A Document Registry is responsible for storing information about those documents so that the documents of interest for the care of a patient may be easily found, selected and retrieved irrespective of the repository where they are actually stored.

Q: Combien de temps avons-nous après la requête ITI-18 pour envoyer la requête ITI-43 ?

A: Vous avez 2 minutes après la requête ITI-18 pour envoyer la requête ITI-43.

Q: Est-ce que je comprends bien la documentation du site confluence: faut-il attendre qq minutes après la requête ITI18 avant de faire ITI-43 ?

A: Non, la requête ITI-43 peut se faire immédiatement après la requête ITI18.

Q:Faut-il faire une requête ITI-18 entre chaque ITI-43? Quid si l’on veut faire plusieurs ITI-43 successifs sur le même document?

A:  Oui, vous pouvez faire plusieurs ITI-43 successifs sur le même document (ou d'autres documents) après une requête ITI-43 et cela pendent 2 minutes.