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

Difference between revisions of "OHF Bridge Documentation"

(API Clarification)
Line 5: Line 5:
 
* Adding a "is PHAD" boolean to the RHIO config
 
* 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)
 
* 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==
 
==API Clarification==

Revision as of 03:23, 8 November 2006

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.

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