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.
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.
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.).
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.
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.
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)
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)
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)
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.
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).
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:
* Where X is an assigned letter from A-Z for the invoking instance.
|| Information entity || XDSs || Version ||
The process of connecting COSMIC with REGIS will be described in this section.
Here you will find the current status and todo-list for the integration setup proces: Status
Updated Booking service (SRV024) createOrUpdateBookedTimeByCommitmentId operation with the new boolean value "updateReferralStatus".
Updated Booking service (SRV024) createOrUpdateBookedTimeByInternalReferralId operation with the new boolean value "updateReferralStatus".
All services wsdl updated with new error enumeration values for external service error (200 and 210)
Updated SRV026_Codes wsdl definition with the added VisitStatus code on the operations createOrUpdateProcedureAndDiagnosisCodesForCommitment and createOrUpdateProcedureCodesForCommitment.
Updated Web Service documentation.
Updated Web Service documentation.
Updated service SRV022_Referral and SRV026_Codes for changes in their wsdl.
SRV022_Referral, added handling of "CosmicReferralStatuses".
Documents A410-00059-18_Integrationsspecifikation for COSMIC PAS i Region Syddanmark.docx and A410-00242-15_Webservice documentation.docx updated to reflect this.
Added Service SRV042_DischargeLetterServiceGoal with its interface.
SRV026_Codes wsdl updated to latest revision (added field visitArt to operations createOrUpdateProcedureCodesForCommitment and createOrUpdateProcedureCodesForLPRContact).
Updated Commitment-xsd (added field previousEndDate).
SRV026_Codes wsdl updated to latest revision (changed operation createOrUpdateDiagnosisCodes to two new operations createOrUpdateDiagnosisCodesForCommitment and createOrUpdateDiagnosisCodesForLPRContact).
Integrationsspecifikation for COSMIC PAS i Region Syddanmark.docx updated to new version.
SRV020_BirthRegistration WSDL interfaces for the service has been added
SRV024_Booking WSDL interfaces for the service has been updated with new changes
SRV022_Referral interface has been updated with a new operation "getReferralsForUnit".
XSDs for pushing Commitments and Contacts has been updated with a message ID (UUID) field and name fields.
SRV022_Referral interface has been updated with new changes (referralWaitingGroup added to response type for both operations).
Added section for the configuration and integration setup between COSMIC and REGIS
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.
Updated XSDs for pushed commitments. Changed referralType to referralWay and made several fields optional.
Uploaded XSDs for pushed commitments.
SRV024_Booking interface has been updated with the new changes.
SRV026_Codes interface has been updated with the new changes.
The changelog will be updated when this work is done.*
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.