Pas services

Changelog last updated 2015-09-10

General information

Applications can request/send information to services exposed at Cosmic Pas by invoking proxied services on the RSD Integration Platform as well as subscribe to pushed information from Cosmic Pas.

Services proxied by the Integration Platform

Cosmic Pas exposes a number of web services in order to send/receive information to the system. The RSD Integration Platform (ESB) acts as a proxy in order to reach those web services (with added flexibility of invoking the services through different protocols for e.g. through MQ as well as web service invocation).

Provided here are the WSDL interfaces for the services on the Integration Platform (ESB) along with documentation for the input parameters. The wsdl interfaces has to be followed regardless of used invoking protocol.


Information pushed from PAS to the end applications

Cosmic Pas sends messages to the RSD Integration Platform which forwards the messages to the applications which subscribes to the information.

Provided here are the XSDs for the pushed information entities. The applications needs to have/implement a Point-of-Delivery (PoD) where the ESB can deliver the message to the applications which subscribe to the information (for e.g. through web services, MQ etc.).


Baseline metadata

Each service on the ESB requires a set of parameters (or baseline metadata) to be set; placed in the Head-tag of the request. This metadata is used for logging/tracing purposes and also maps the invoking instance to a defined contract.

Property Comment
Required?
IntegrationId
The Id for the entire transaction of the business entity, e.g. INT001.
ContractId
The Id contains the unique identifier for an invocation of a service, e.g. SRV011A.
LogicalId
An Id containing the business identifier for an entity, e.g. the order number or employee social ID.
LogicalIds
LogicalIds as type/value pairs (preferable over logicalId)
TransactionId
The Id is used as an identifier for a message transaction.


SOR conversion

Cosmic Pas uses SOR ids for describing units. Since not all invoking applications use SOR ids for describing units the services on the integration platform can map between different unit types (for e.g. SKS codes). If a service includes unitIds in the request/response, the invoking instance must supply a property letting the service know to/from which unit type the ids should be mapped. If no property can be found in the request, the service will assume the invoking application can handle SOR ids and will not map the request/response.

The Property to set is called UnitType and is set in the Head tag of the request under Head/properties.

Example:

<Head>
   <properties>
      <name>UnitType</name>
      <value>UNIK-SHAK-MAP</value>
      <type>java.lang.String</type>
   </properties>
</Head>

The mapping database at the integration platform should contain all available units to map to/from, but if a specific unit cannot be found, the service will return an error with errorCode 20.

Unit types currently available in the ESB test database: (Use the UnitType in the value field of the property)

UnitType Comment
SLB_ext_SHAK Subset of SKS codes
UNIK-SHAK-MAP Subset of official SKS codes (maximum 7 characters long)

Authorization

Invoking services at Cosmic Pas requires authentication in the form of a Base64 encoded username:password String. This authentication is sent to the services on the esb as a property (encoded or not encoded) which will authenticate the request (this will also identify the requestor to Cosmic).

The property to set is called Authorization and is set in the Head tag of the request under Head/properties.

Example: (where username:password is not Base64 encoded)

<Head>
   <properties>
      <name>Authorization</name>
      <value>username:password</value>
      <type>java.lang.String</type>
   </properties>
</Head>

The username:password can be sent either Base64 encoded (prefered) if the application is able to or simply as a string with the username:password. If the string is already Base64 encoded, it should begin with the String "Basic ". Otherwise simply have the String state username:password.

Example (where username:password is Base64 encoded)

<Head>
   <properties>
      <name>Authorization</name>
      <value>Basic dXNlcm5hbWU6cGFzc3dvcmQ=</value>
      <type>java.lang.String</type>
   </properties>
</Head>

DateTime

The xsd DateTime field is always converted to UTC time by the integration platform. This means it's important for the sender/receiver of the information to correctly identify the time-zone for the dateTime as it's interpreted. As by the xsd:dateTime conventions a DateTime will be sent with the letter 'Z' denoting the UTC time.

Example

   <Body>
      <contactId>1234567</contactId>
      <dischargeType>1</dischargeType>
      <dischargedToUnit/>
      <dischargeDate>2011-08-09T10:53:00Z</dischargeDate>
   </Body>

Documentation for integration specification

Have in mind that the analysis of the integrations is an ongoing process and that the specification might be changed in the future.
Document Comment
A410-00059-24_Integrationsspecifikation for COSMIC PAS i Region Syddanmark.DOCX The current version of the Integration Specification. Have in mind that this is the high level description of the integrations. For a specific service description including the actual in/output parameters, please refer to the WSDLs and the service documentation.
A410-00557-03_Systembeskrivelse for modtagelse af bookingsvar fra RIS i COSMIC PAS.DOCX Specification of how booking information is received and stored in COSMIC by XDIS13 messages
A410-01349-04_Systembeskrivelse for røntgenintegrationen.DOCX
Teknisk systembeskrivelse for røntgenintegrationen til COSMIC.
A410-00227-02_LPR-indberetningen i COSMIC.pptx Specification of registration in COSMIC is connected to the LPR reporting. From slide 109 pp. this is specific to the XRAY integrations
EMAR specific documentation
Document Comment
A410-00294-02_Modtagelse af henvisning i EMAR.docx A description of how referrals are received in COSMIC and EMAR. The information in this document will be merged into the integration specification.
A410-00295-02_Overførelse af bookinginformationer fra EMAR til COSMIC PAS.docx A description of how phase II of the integration between EMAR and COSMIC is supposed to be regarding booking information.


Documentation for services

The Body-tag contains the proxied request for the web services at Cosmic Pas (explaining why the documentation for the input parameters is the same as the Cosmic Pas web services).

Document Comment Version
A410-00242-27_Webservice documentation.docx Documentation for the web services at Cosmic Pas. All input parameters proxied by the services on the Integration Platform in the Body-tag.
18-04-2016
A410-00275-01_Error Handling in COSMIC Services.DOCX Documentation for error handling at web services at Cosmic Pas. The error message from Cosmic Pas will be proxied by the Integration Platform in the Fault method of the invoked service
 
A410-00190-03_UserAdmin Webservice documentation.docx Documentation for the user admin webservices in COSMIC.
 
A410-00719-02_XML Schema dokumentation.docx Documentation for the XML schemas used for pushing Contacts, LPRContatcs and commitments.
R2.0.9
A410-00394-02_Technical Specification of synchronous ReferralService.docx
Documentation of the technical specification of the synchronous ReferralService
 
A410-00734-03_Technical Specification of synchronous BookingService.docx
Documentation of the technical specification of the synchronous BookingService
 

Handling of errors

On top of the error documentation by Cosmic Pas, the Integration platform can also send back errors in the fail output if an error occurred before the request reached Cosmic Pas. To see where the error occured, check the errorCode in the reply-message:

  • Error code < 10 means that there was an internal error at the Integration Platform.
  • Error code 10 =< x < 100 means that there was a logical error at the Integration Platform.
  • Error code 100 =< x < 200 means that the service could be reached at Cosmic Pas, but Cosmic Pas returned an error
  • Error code 200 =< x < 300 means that the service couldn't be reached at all at Cosmic Pas
Code Comment
1 An internal error occurred at the Integration Platform (these are unmodelled errors).
10 Baseline metadata error. Check that the supplied BaselineHeader is correct and that the IntegrationId and the ContractId are correct. Check the supplied error message for error description.
20 Database error. Not all units could me mapped to/from SOR ids.
100 Service error at Cosmic Pas. Check the supplied error message for error description.
110 Service unavailable at Cosmic Pas (But responding).
200 Error at the Cosmic Pas service (most likely it can't be reached at all).
210 Authorization error at Cosmic Pas service - check username and password used


WSDL interfaces for the services on the Integration Platform

The interfaces for these services are currently being developed. Changes to input-parameters/name-spaces and other elements might occur during development.
Service WSDL IntegrationId ContractId Comment
 SRV011_Contact SRV011_Contact.wsdl INT001
SRV011X *
 
 SRV013_JournalNote SRV013_JournalNote.wsdl INT003
SRV013X *
 
 SRV020_BirthRegistration SRV020_BirthRegistration.wsdl INT006
SRV020X *
 
 SRV022_Referral SRV022_Referral.wsdl INT007
SRV022X *
 
 SRV024_Booking SRV024_Booking.wsdl INT008
SRV024X *
 
SRV026_Codes
SRV026_Codes.wsdl
INT009
SRV026X *
 
SRV042_DischargeLetterServiceGoal
SRV042_DischargeLetterServiceGoal.wsdl
INT010
SRV042X *
 
PersonService
PersonService.xml
    Interface where cpr updates are pushed to COSMIC.

* Where X is an assigned letter from A-Z for the invoking instance.


XSDs for the pushed information entities

The xsds are currently being developed. Changes to parameters/name-spaces and other elements might occur during development.

|| Information entity || XDSs || Version ||

Contact
Contact-xsds
R2.0.9
LPRContact
LPRContact-xsds
R2.0.9
Commitment
Commitment-xsds
R2.0.9


Integration Setup

The process of connecting COSMIC with REGIS will be described in this section.

Status

Here you will find the current status and todo-list for the integration setup proces: Status

Changelog

Since most of the artifacts on this page is under development, check for changes posted in this changelog

10 September 2015

Updated Booking service (SRV024) createOrUpdateBookedTimeByCommitmentId operation with the new boolean value "updateReferralStatus".

25 June 2015

Updated Booking service (SRV024) createOrUpdateBookedTimeByInternalReferralId operation with the new boolean value "updateReferralStatus".

1 September 2014

All services wsdl updated with new error enumeration values for external service error (200 and 210)

22 February 2013

Updated SRV026_Codes wsdl definition with the added VisitStatus code on the operations createOrUpdateProcedureAndDiagnosisCodesForCommitment and createOrUpdateProcedureCodesForCommitment.

21 December 2012

Updated Web Service documentation.
Updated Contact XSD with added end date field for Contct push services.

6 November 2012

Updated Web Service documentation.

21 September 2012

Updated service SRV022_Referral and SRV026_Codes for changes in their wsdl.

SRV022_Referral, added handling of "CosmicReferralStatuses".
SRV026_Codes, added operation "createOrUpdateProcedureAndDiagnosisCodesForCommitment".

Documents A410-00059-18_Integrationsspecifikation for COSMIC PAS i Region Syddanmark.docx and A410-00242-15_Webservice documentation.docx updated to reflect this.

6 July 2012

Added Service SRV042_DischargeLetterServiceGoal with its interface.
Updated SRV024_Booking wsdl to conform to new operations at Cosmic Pas.

21 June 2012

SRV026_Codes wsdl updated to latest revision (added field visitArt to operations createOrUpdateProcedureCodesForCommitment and createOrUpdateProcedureCodesForLPRContact).

Updated Commitment-xsd (added field previousEndDate).

7 June 2012

SRV026_Codes wsdl updated to latest revision (changed operation createOrUpdateDiagnosisCodes to two new operations createOrUpdateDiagnosisCodesForCommitment and createOrUpdateDiagnosisCodesForLPRContact).

20 April 2012

Integrationsspecifikation for COSMIC PAS i Region Syddanmark.docx updated to new version.

17 April 2012

SRV020_BirthRegistration WSDL interfaces for the service has been added

5 January 2012

SRV024_Booking WSDL interfaces for the service has been updated with new changes

17 November

SRV022_Referral interface has been updated with a new operation "getReferralsForUnit".
SRV026_Codes interface has been updated with an "amount" field in incoming request.

XSDs for pushing Commitments and Contacts has been updated with a message ID (UUID) field and name fields.

19 May 2011

SRV022_Referral interface has been updated with new changes (referralWaitingGroup added to response type for both operations).

6 May 2011

Added section for the configuration and integration setup between COSMIC and REGIS

5 May 2011

Updated XSDs for pushed commitments. Added refferalPhysicianName field ( = Henviser). The change will be uploaded to the server as part of the next scheduled update, which occurs the 17th of May, if all goes according to plan.

17 March 2011

Updated XSDs for pushed commitments. Changed referralType to referralWay and made several fields optional.

15 March 2011

Uploaded XSDs for pushed commitments.

27 January 2011

SRV024_Booking interface has been updated with the new changes.

26 January 2011

SRV026_Codes interface has been updated with the new changes.

19 January 2011

SRV024_Booking will undergo changes:

The changelog will be updated when this work is done.*

  • The interface will have changed its operations.

7 January 2011

SRV026_Codes will undergo changes:

The changelog will be updated when this work is done.

• createProcedureCodesForLPRContact/createProcedureCodesForCommitment og updateProcedureCodes bør slås sammen til metoderne createOrUpdateProcedureCodesForLPRContact/createOrUpdateProcedureCodesForCommitment.

Rationale: Hvis der fejl i procedurekoderne, når de først oprettes i kundens system, så afvises opret-beskeden af create-servicen i PAS. Derefter retter kunden procedurekoderne i deres system, og kundens system sender en ret-besked til PAS. Men ret-beskeden afvises også, da vi med den nuværende metodesignatur ikke har mulighed for at oprette på baggrund af en ret-besked. Kunden bliver i stedet tvunget til at slette procedurekoderne i deres system og oprette dem igen, for at få sendt en ny opret-besked til PAS. Det giver en omstændig arbejdsgang og en unødig kompleks snitflade at vedligeholde.

• Metoden createDiagnosisCodes bør også omdøbes i samme omgang – den er allerede specificeret som en opret/ret i Integrationspecifikationen (A410.59.9), men det fremgår ikke af navnet.

• Parameteren ’time’ til metoden createDiagnosisCodes er flyttet fra ’Code’ typen og ud som en selvstændig parameter (den angives kun en gang, i stedet for for hver kode). Den ændring står i Integrationspecifikationen (A410.59.9) og den er også trådt i kraft i koden.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.