Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

OHF Bridge Documentation

Revision as of 04:08, 8 November 2006 by Unnamed Poltroon (Talk)

This page will try to supply missing documentation problems occurring due to the frequent updates and new requirements we receive from the IHE Connectathon 2007 tests.

Changes in Beta 3 Web services API

  • Changing pidType to patientIdType in order to avoid HL7 namespace conflicts.
  • Adding a "is PHAD" boolean to the RHIO config
  • Changed the names of the send document operations and added one that suits the IHE Connectathon 2007 most (see API clarifications)
  • In the XDSDocType, changed the name of EncodedDocument to Base64EncodedDocument

API Clarification

Sending documents

In beta 3 we've changed the name of the methods to reduce misunderstanding and added one that should be used at the connectathon.

  • WrapInCdaAndSubmitDocument (was SubmitDocument): This operation receives a XDSDocType which is an object that contains a document encoded using base64. The base64 document is sent in the EncodedDocument (changed to Base64EncodedDocument) field of the XDSDocType. The bridge contracts a CDA using a default template, embeds the base64 document in the CDA and use the XDSDocType metadata fields (documentTitle, patientInfo, etc.) to populate the CDA and metadata XMLs.
    • This operation is fast and dirty. It gives the bridge a lot of control on the CDA creation and it is for applications that have problems creating CDA documents and just want to upload PDF files or images.
    • We recommend not to use this operation in the Connectathon.
  • ExtractMetadataAndSubmitDocument (was SubmitRawDocument): This operation tried to extract metadata from the document and use it to send the document. The type parameter is to understand what types of documents you're about to send (CDA, DICOM, ...). Currently only CDA is supported, so the only option that will work is "CDA". The patientId parameter was removed since it is taken from the document.
    • This operation also fast and dirty (though a bit less). It gives the bridge a lot of control on the Metadata creation and it is for applications that have problems creating metadata documents and just want to upload CDA files.
    • We recommend not to use this operation in the Connectathon.


General comment regarding the "DecodedDocument" field. Please ignore it. We had placed it there to overcome a problem we had with SOAP object translation and we intend to remove it soon.

Back to the top