RLUS and IS. Smart Open Services for European Patients. Open ehealth initiative for a European large scale pilot of

Transcription

1 Smart Open Services for European Patients Open ehealth initiative for a European large scale pilot of patient summary and electronic prescription RLUS and IS 12 WORK PACKAGE 3.3 DOCUMENT NAME RLUS and IS SHORT NAME DOCUMENT VERSION n/a 0.1 Draft for Discussion DATE 06/10/

2 15 COVER AND CONTROL PAGE OF DOCUMENT Document name: RLUS and IS Distribution level WP 3.4 Status 0.1 Draft for Discussion 02 FileName WP3.3-RLUS_IS_v0.1-DraftForDiscussion02.doc Author(s): Stefano Lotti, Giorgio Cangioli Organization: Regione Lombardia Dissemination level: PU = Public, PP = Restricted to other programme participants, RE = Restricted to a group specified by the consortium, CO = Confidential, only for members of the consortium. ABSTRACT This document provides discussion items concerning why and how the standards services RLUS and IS may be applied for the scope of this project 18 History of Alteration Version Date Status Changes From Review /10/2009 First draft for Discussion Stefano Lotti

3 Table of contents 1 FOREWORD INTRO: NCP GATEWAY SERVICES ARCHITECTURE THE HEALTHCARE SERVICE SPECIFICATION PROJECT (HSSP) WHAT ARE RLUS AND IS RLUS - RETRIEVE, LOCATE, AND UPDATE SERVICE RLUS SFM RLUS STM RLUS Implementation IS - IDENTIFICATION SERVICES IS SFM IS STM IS implementation WHY RLUS AND IS NATIONAL PLATFORMS INDEPENDENCY ENTITY AND INFORMATION MODELS INDEPENDENCY FLEXIBILITY AND SCALABILITY SOA AND XDS STANDARDS DIRECTION RLUS AND IS: HOW TO FUNCTIONAL PROFILE RLUS Generic Service OrderService DispensionService PatientService IS SEMANTIC PROFILE WSDL of 56

4 RLUS Patient Service Order Service Dispension Service Generic RLUS Service RLUS SOAP example Inizialize Operation example inizializerequest inizializeresponse IS IS SOAP Example findidentitiesbytraits Operation example Example of findidentitiesbytraits request Example of findidentitiesbytraits response REFERENCES

5 Table of figures Figure epsos NCP Gateway Services Architecture... 7 Figure The HL7/OMG relationship In HSSP... 8 Figure RLUS Normative Management and Query Interface Figure IS Normative Management and Query Interface Figure 4-1 XDS and Services Figure epsos RLUS capability Figure 5-2 OrderService Figure 5-3 DispensionService Figure 5-4 PatientService Figure 5-5 epsos IS Figure Patient Service WSDL (Graph) Figure Order Service WSDL (Graph) Figure Dispension Service WSDL (Graph) Figure 5-9 RLUS generic Service WSDL (Graph) Figure IS WSDL (Graph)

6 Foreword This document provides discussion items concerning why and how the standards services RLUS 1 and IS 2 may be applied for the scope of this project. The document is completed by two file RLUS_epSOS_ zip and IS_epSOS_ zip with WSDL schema and some SOAP example. 1 2 RLUS stands for Retrieve, Locate, and Update Service and it is a product of HSSP - Healthcare Service Specification Project, a collaborative effort between OMG and HL7 ( IS (formerly known as EIS Entity Identification Services) stands for Identification Service (IS) Service and it is a product of HSSP - Healthcare Service Specification Project, a collaborative effort between OMG and HL7 ( 6 of 56

7 Intro: NCP Gateway services architecture The NCP gateway have the responsibility to realize the wrapping of national infrastructure, for a sake of simplicity the diagram represent only the binding for a Country B provider of epsos services and a Country A consumer of epsos Services but every NCP Gateway have service and request port and thus can act like, simultaneously, a provider and consumer of epsos services. The Figure 2-1 shows the high level view of the Service Architecture of an NCP Gateway 3. The type of capabilities is realized by a set of service contract realized by the NCP gateway Figure epsos NCP Gateway Services Architecture The service defined for epsos-1 at this time is: An Identification Service that support the identification of a patient in a foreign country A group of services for the data exchange: PatientService for the Patient summary exchange OrderService for the eprescription exchange DispensationService for the notification of a dispensation of an epsos eprestiption 105 A service for the Consent exchange can be set when the process will be clarified. 3 The diagram is a UML collaboration with the use of [OMG SoaML] profile. 7 of 56

8 In this document we present a binding between this service contract and the RLUS and EIS standard and a justification of the use of this standard 4. The binding between ServiceContract and the proposed standards is the following: (1) IS might be used for the IdentificationServices (2) RLUS for the PatientService, OrderService, DispensationService 2.1 The Healthcare Service Specification Project (HSSP) RLUS and EIS is products of HSSP - Healthcare Service Specification Project 5, a collaborative effort between HL7 and OMG. The objectives of the HSSP include: To facilitate the development of a set of implementable interface standards supporting agreed-upon services specifications to form the basis for provider purchasing and procurement decision. To stimulate the adoption and use of standardized plug-and-play services by healthcare software product vendors To complement and not conflict with existing HL7 and OMG work products and activities, leveraging content and lessons learned from elsewhere within both organizations Figure The HL7/OMG relationship In HSSP Figure 2-2 represent the standardization process of HL7/OMG collaboration in HSSP. HL7 have the responsibility for the Service Functional Model (SFM) Specification and OMG for a detailed services specification (STM - Service Technical Model). 4 The machine readable supplements of this document is RLUS_epSOS_ zip and IS_epSOS_ zip HSSP, The HSSP Roadmap, Version 1.0, 02/10/2007 ( 8 of 56

9 HL7 identifying functional requirements, information needs, and conformance criteria. These requirements are laid out in a Service Functional Model (SFM) for each HSSP service. SFMs are specifications developed and balloted by HL7 using normal HL7 processes. The OMG uses the SFM to develop a Request for Proposal (RFP), the basis of the OMG standardization process that achieves the STM standard. OMG members (submitters) respond by proposing solutions that satisfy the requirements expressed in the RFP. HSSP insures that the HL7 membership remains actively involved throughout the RFP creation and submission evaluation process. HSSP have a series of liaisons with IHE, Eclipse OHF, OpenEHR Other HSSP project (at different stage of completion) are: CTS2 (Common Terminology Services 2) DSS (Decision Support Service) HCPDS (Healthcare Provider and Services Directory Service) PASS (Privacy, Access and Security Services) H-SOA-RA (Healthcare SOA Reference Architecture) 9 of 56

10 What are RLUS and IS 3.1 RLUS - Retrieve, Locate, and Update Service RLUS stands for Retrieve, Locate, and Update Service and it is a product of HSSP. It is a service specification that seeks to define, at a service level, appropriate interfaces to locate, retrieve, and update resources among and between healthcare organizations. It is not intended to replace existing systems or implementations, but to create an interface standard for a service-oriented layer to expose those healthcare assets and resources within an organization that are needed to meet business or medical needs. 7 The RLUS standard is actually - on the OMG side - in Finalization Task Force phase, so it is an approved standard where only editorial and minor changes will be in the final version (expected in October); as for the HL7 SDO is on DSTU (Draft Standard for Trial Use) state (since 2006). The reference specifications for this service are: Service Functional Model (SFM): HL7 Version 3 Standard: Resource Location and Updating Service, Release 1 December 2006 (DTSU) Service Technical Model (STM): OMG, Retrieve, Locate, and Update (RLUS) Service Specification, dtc/ , (FTF) RLUS SFM The SFM identifies the following interfaces: Administrative and Management Interface: Administrative and management interfaces are services that change the quantity or quality of meta-information being exposed by RLUS. Semantic Interface Semantic interfaces include service interfaces that delimit the underlying informational qualities of RLUS, including the semantics to use as query parameters, the semantics for return values, and the enumerated semantic structures available within a resource Run-Time Interface: Run-time interfaces expose functional capability that is intended to be implemented to expose underlying functionality 7 OMG 10 of 56

11 The RLUS SFM defines a set of profiles that cover specific functions, semantic information and overall conformance. In short, they are as follows Functional Profile: a named list of a subset of the operations defined within this specification which must be supported in order to claim conformance to the profile. Semantic Profile: identification of a named set of information descriptions (Semantic Signifiers) that are supported by one or more operations (e.g. a CDA2 template or a HL7 message). Conformance Profile: this is a combination of a set of functional and semantic profiles taken together to give a complete coherent set of capabilities against which conformance can be claimed SFM specification defines functional profiles (see table below) for RLUS, but no normative profiles (conformance, semantic, functional) has been defined. Therefore, there are no normative functional or semantic profiles.... Profiles are not normative except within the context of a conformance profile in a deployment context. Additional profiles may be created reflecting local requirements or on a larger scale. 8 Table 3-1 RLUS functional profiles Profile Name Included Functionality Location List Conformance Profiles List Semantic Signifiers Locate Resources by Resource Parameter Retrieval List Conformance Profiles List Semantic Signifiers List Semantic Signifiers for Resource Retrieve Semantic Signifier Retrieve Resource Retrieve Resources by Resource Parameter Update List Conformance Profiles List Semantic Signifiers Create Resource Update Resource Delete Resource Administrative List Semantic Signifiers Create an RLUS Entry Update an RLUS Entry Delete an RLUS Entry List Conformance Profiles Locate and Retrieve (Extended) List Conformance Profiles List Semantic Signifiers List Semantic Signifiers for Resource Locate Resources by Resource Parameter Retrieve Resources by Resource Parameter 8 HL7, HL7 Version 3 Standard: Resource Location and Updating Service, Release 1 December 2006 (DTSU), 11 of 56

12 RLUS STM The STM 9 standard implement an interfaces subset: the RLUS Management and Query Interface, including the following operations : Get (retrieving a single logical record); List (returning a list of logical record instances); Locate (returning a list of RLUS service); Put (writing an instance of the logical record); Discard (discarding an instance of the logical record) ; Describe (get detailed schema definition) ; Initialize (It is a variation of the Put() operation and is utilized to handle specific interoperability scenarios. Specifically, when an RLUS information network is assembled, network participants add data to that network through system generated events which require different rule processing than might be required for the Put() operation) Figure RLUS Normative Management and Query Interface 202 The RLUS Meta Data Interface, including the following operations: CreateSemanticSignifier (This operation provides the means to create a semantic signifier definition) 9 OMG, Retrieve, Locate, and Update (RLUS) Service Specification, dtc/ , 12 of 56

13 FindSemanticSignifier (This operation provides the means to retrieve the semantic signifier definition by name) UpdateSemanticSignifier (This operation provides the means to update a semantic signifier structure) ListSemanticSignifier (This operation provides the means to list all available semantic signifiers that a RLUS service implementation supports) ListConformanceProfile (Returns the list of named conformance profiles that the service implementation supports) Each implementation of this service shall define its own Conformance Profile, i.e. a combination of a set of functional and semantic profiles taken together to give a complete coherent set of capabilities. In few words it means that a real world service implementing RLUS is expected to declare: the list of operations offered (or invoked) [e.g. Retrieve Resources by Resource Parameter] the types of entity managed [e.g. Patient Summary] the way the entity information are encoded [e.g. HL7 V3 CDA2] RLUS Implementation In the section RLUS and IS: how to an example of summarized conformance profile for a possible epsos implementation will be done. 3.2 IS - Identification Services IS (formerly known as EIS Entity Identification Services) stands for Identification Service (IS) Service and it is a product of HSSP - Healthcare Service Specification Project. The scope of this specification is the interfaces, operations, and information structure required to uniquely identify various kinds of entities within disparate systems within a single enterprise and/or across a set of collaborating enterprises. These service interfaces are intended to be used within a healthcare setting, in which the security of data exchanges is both important and regulated by laws. 10 The reference specifications for this service are: Service Functional Model Specification (SFM): Identification Service, Version 2.0, Normative Ballot, September Service Technical Model (STM): Entity Identification Service (EIS) Specification, dtc/ , (FTF) OMG 13 of 56

14 IS SFM This SFM specification identifies two interfaces: The Identification Management interface, that offers operations for manipulation of Identifiers and properties. The Query interface, that offers read-only capabilities for retrieving Entity information Only the latter seems to be of interest for the epsos-1 project. This interface provides the following functions: Get All Information for an Identity Retrieves all information for an Identity known by the IS (properties, status etc). A specific unique identifier is input (qualified by Jurisdictional Domain and Entity Type). Find Identities by Property Given a partially populated semantic signifier and other search filter criteria, this allows for a search of matching Entities. List Linked Identities : Given an Identifier, list all other entities that are linked to the Identity (optionally constrained within one or more Jurisdictional Domains) Request Identity Update Notifications The service consumer lodges a request to be notified if the IS becomes aware of any changes to information for a specific Identity (properties, status or entity links) or identities of a specific type and/or domain combination Update Identity Notification Request The service consumer provides an update to a previously submitted request to be notified if the IS becomes aware of any changes to information for a specific Identity (properties, status or entity links) or identities of a specific type and/or domain combination. This includes cancellation of the request Notify Identity Updates The service produces a notification of an update that has been made to any information relating to a specific identity or identities within a Jurisdictional Domain and/or Entity Type (previously notified by a Request Update Notifications request. Although, IS SFM specification defines some functional profiles (see table below), a specific implementation of this service shall define its own Conformance Profile, i.e. a combination of a set of functional and semantic profiles taken together to give a complete coherent set of capabilities. Where a: Functional Profile is intended to be a named list of a subset of the operations defined within the SFM specification which must be supported. Semantic Profile : is the identification of a named set of information descriptions (semantic signifiers) that are supported by one or more operations. In the case of the IS specification, this must identify both the Entity itself (e.g. Patient) and the Model or Classification Scheme from which it is taken (e.g. HL7 V3 RIM V2-14). This will formally define the meaning of entities and the sets of properties. In the case of HL7 based profiles, this will provide crossreferences to the appropriate RIM-based domain models for the entity and each property. 14 of 56

15 272 Table IS functional profiles Profile Name Included Functionality Identity Cross-Reference v1.0 Identity Update v1.0 Identity Merge v1.0 Identity Query v1.0 Identity Update Notification v1.0 Link Identities Unlink Identities List Linked Identities Register Identity Create Identity Update Identity Property Values Update Identity Status Merge Identity Unmerge Identity Get All Information for Identity Find Identities by Property Request Identity Update Notifications Notify Identity Updates No normative conformance is defined, in the same way of RLUS IS STM The STM Standard Implement tree interface: ManagementAndQueryInterface AdminEditorInterface MetaDataInterface As already defined only a functional subset of ManagementAndQueryInterface seems to be of interest for the epsos-1 project. 11 However for IS is expected that HL7 semantic profile can be managed and balloted within HL7. 15 of 56

16 Figure IS Normative Management and Query Interface The operation of interest correspond to Identity Query profile: findidentitybytraits getentitytraitvalues IS implementation In the section RLUS and IS: how to an example of summarized conformance profile for a possible epsos implementation will be done. 16 of 56

17 Why RLUS and IS The reasons why RLUS and IS standards should be preferred for the epsos project are several; hereafter a summarization of some of them (we deem important for our scope). 4.1 National platforms independency As pointed out within the D3.3.1 epsos Sistem Technical Specification 12 document the epsos mission is to demonstrate the European cross-border interoperability in healthcare field independently from the implementation choices of every Member State and, due to the heterogeneity of systems and protocols of different members state, the architecture adopted must be abstracted from the complexity-characteristic-platform of underlying systems (loose coupling principle). IS and RLUS guarantee that, other solutions might not. (e.g. XDS supposes a specific platform adoption: ebxml) 4.2 Entity and Information models independency Further to the previous paragraph statements, functionalities involved in identification (or retrieval) might need to deal with different kinds of entities, each one possibly encoded with different structures. The usage of an unique interface for all of them (therefore defining a more abstract level for the service) may, from a technical or systems development perspective, enable common frameworks and applications to be built and significant reuse to be achieved; from a business perspective, provide greater flexibility and would allow re-classification of entities and roles without the need to change the service interfaces. Both IS and RLUS allow to provide a set of interfaces through which information systems can access and manage information independently, but compatible with, underlying structures and data models. That is, the interfaces and operations provided may be equally valid for patients, providers, and many other kinds of entities; moreover, for a specific entity (e.g. Patient) several information models may be adopted (e.g. HL7 V3 RIM; HL7 V2, others, ). 4.3 Flexibility and Scalability Flexibility and scalability are proprieties strongly recommended for an interoperability project as epsos. As previously explained, solutions for which the problem of interoperability is abstracted away from underlying systems; and for which is possible a re-classification of entities and roles without the need to change the service interfaces should be preferred. IS and RLUS assure that. 12 WP 3.3 Architecture, D3.3.1 Draft epsos System Technical Specification, Internal Wp3.3 Review Version, 28/09/2009. See, REQ 3.3.2, 3.3.3, 3.3.4, pages of 56

18 Furthermore an alternative project-specific legacy interface must be avoided as it led to the fragility and rigidity of epsos architecture. epsos must have a coherent and complete service architecture design with the possibility to extend the operation and entity as used in epsos-1 to support new use case in a epsos-n or in other similar healthcare interoperability European Project. Conversely a project specific interface will require an interface reengineering if a new scenario emerge. IS and RLUS assure that. 4.4 SOA and XDS (This section is taken with slight modifications from epsos Architecture Vision document) XDS 13 is a standard based implementation 14 of a community infrastructure for document exchange. The XDS specification describes the specific transaction and the technology used 15. Moreover we must consider that XDS is a pre-soa architecture. In the context of epsos XDS is a possible choice for a national/regional infrastructure and thus XDS live in a different problem space from epsos project. The figure 4-1 is taken 16 from a recent IHE whitepaper 17 and clearly represents the correct context for XDS specification. In this paper IHE recognizes the correct position of XDS against a modern service oriented interoperability: The focus of the paper is to illustrate how healthcare interoperability can be addressed by leveraging IHE profiles in an SOA design. While it is possible to simply re-factor an IHE Profile into an SOA service, the greater benefit of using SOA might be gained through building more purposeful services that leverage one or more IHE profiles. 18 The true problem space of epsos project is in the Gateway boundary (in figure) and, as noted, is not possible to make any assumption of implementations choice of the member state (can be an XDS infrastructure or, more likely, can not be). For the epsos objective IHE work is very useful, but only the profiles without technology implementation dependences can be used in epsos service space (e.g. Audit trail), the other aspects of IHE profile and especially XDS are in the domain of a national/regional infrastructure IHE, IT Infrastructure Technical Framework, Vol 1 e 2, Revision 5.0, December 12, We consider the complete XDS family specification (e.g. XDSa XDSb XCA) The approach employed in the IHE initiative is to support the use of existing standard rather than to define new standards. (IHE, IT Infrastructure Technical framework, Vol. 1 & 2, Rev. 5.0, 2008) XDS is based on a creative use of an ebxml registry. With little modification. IHE, A Service-Oriented Architecture (SOA) View of IHE Profiles, White Paper, Public Comment, May 8th 2009 IHE, A Service-Oriented Architecture (SOA) View of IHE Profiles, White Paper, Public Comment, May 8th of 56

19 Standards direction Figure 4-1 XDS and Services 19 All the principal healthcare IT standards and profiles are more and more moving towards SOA With HSSP, Health Level Seven started a collaborative effort with Object Management Group to identify and document service specifications, functionality, and conformance supportive and relevant to healthcare IT stakeholders and resulting in real-world implementations with SAEAF (Services-Aware Enterprise Architecture Framework) project HL7 is harmonizing all of the HL7 s Interoperability Paradigms, i.e. messages, documents, and services within the context of the goal of Working Interoperability (HSSP collaborate at this effort). IHE has released a white paper 20 to show how IHE profiles can be used to leverage SOA solutions. A liaison between IHE and the HSSP project has also been established to harmonize HSSP standards and IHE profiles to the maximum extent possible RLUS and IS (products of HSSP) in this general context are the most accredited standards for the SOA convergence in healthcare field (within the context these services operate) Strictly based on: IHE, A Service Oriented view of IHE Profile, Public Comment, 8 may IHE, A Service-Oriented Architecture (SOA) View of IHE Profiles, White Paper, Public Comment, May 8th of 56

20 RLUS and IS: how to This section gives a proposal for implementation of these services within the epsos project. If adopted, IS and RLSU services will require a more detailed analysis and service specification against other WG release. The machine readable file supplement of this section is RLUS_epSOS_ zip and IS_epSOS_ zip 5.1 Functional profile This section described the sub set of RLUS and IS capabilities supported by this implementation RLUS Different approaches may be taken for the RLUS implementation, for example we could: either create a specific WSDL for each data type considered (Patient Summary, eprescription, edispension,..) and then types the semantic signifier payload to the specific operations or use generic signifiers to represent the data payloads. In this case the caller could dynamically determine the required schema definition via the Describe() operation inspecting it at run-time Depending on the choice made, and in case on document type, different functional profile should be defined. In general as noted in RLUS Standard 21 is possible to create a specific WSDL for each data type (Patient, Order, and Immunization) and then types the semantic signifier payload to the specific operations. Now this could also be done more generically, with an RLUS-HSSP interface with only generic signifiers to represent the data payloads and then the caller could dynamically determine the required schema definition by inspecting it at run-time via the Describe() operation. This is similar to using an any or variant data type instead of a specific structure to represent the data payload. The specific WSDL, moreover, is more type-safe and has some advantages when using modern web service development tools since the more type explicit approach allows the development tools to create object wrappers around the explicit data types, where the generic approach requires the developer to write code against the XML text format of the semantic signifier directly of 56

21 Generic Service In case of non-specialized service, functional profile includes all the RLUS Management and Query Interface operations excluding put, i.e.: Get (retrieving a single logical record); List (returning a list of logical record instances); Locate (returning a list of RLUS service); 392 Discard (discarding an instance of the logical record) ; Describe (get detailed schema definition) Initialize (used to send a record from an internal source system onto a RLUS network) Figure epsos RLUS capability OrderService The service used for the management of Orders (OrderService) will have instead only the following operations: Get (retrieving a single logical record); List (returning a list of logical record instances); Locate (returning a list of RLUS service); 21 of 56

22 Figure 5-2 OrderService DispensionService Information about supplied materials will be managed via two operations: Initialize. (making other NCPs known about epresciprion dispension.) Discard. (nullifying erroneously notified dispension); Figure 5-3 DispensionService PatientService As for the management of Patient History documents it has been considered these two operations: 22 of 56

23 Get (retrieving a single logical record); List (returning a list of logical record instances); even if - since only one patient summary at a time may be active for a patient - the only get operation would be enough for the epsos implementation Figure 5-4 PatientService IS IS implementation will realize, instead, the Identity Query v1.0 Functional Profile Semantic profile Figure 5-5 epsos IS It is out of the scope of this document the definition of the informational content and encoding, in charge of other WPs. 23 of 56

24 In this section we provide, only for the sake of exemplification, a possible solution for the IS service in terms of semantic profile and payload (input, output) structure. As above mentioned, since different approaches may be taken for the services implementation, semantic profiles will change depending on the choice made,. The specialized solution is reported in the Errore. L'origine riferimento non è stata trovata., describing possible semantic profile options for epsos, as option 1; the generic one as option 2. Table Semantic Profiles Options Entity Semantic Signifier 22 RLUS (Option 1) Document HL7 CDA R2 RLUS (Option 2) Patient Summary HL7 CDA R2 + Patient Summary Template eprescription edispension HL7 CDA R2 + eprescription Template HL7 CDA R2 + edispension Template IS Patient HL7 RIM V specific LIMs It reasonable to consider that LIM used in this context will be derived from R-MIMs (Refined Message Information Model) associated to interactions belonging to the Patient Registry Find Candidates Query 24 (PRPA_ST201305UV02); and Patient Registry Get Demographics Query (PRPA_ST201307UV02) storyboards. 5.3 WSDL In this section are described some examples of service contracts may be used for epsos. The WSDLs reported hereafter, based on wsdls provided by OMG with STM documentation, are provided only for sake of exemplification, and limited for the RLUS service to the specialized service case 25 If necessary, more specific WSDL for epsos will be defined further on. 22 Semantic Signifier symbolizes the information structure used to represents the Entity type managed by the service. 23 Localized Information Model: A LIM is a serializable model that is a valid constraint on a CIM. CIMs currently define message structure and semantics that may be sent over the wire using the XML implementation technology specification, this includes the naming of the XML tags. LIMs are implented as constraints on this wire protocol and can define further restrictions on content allowed. (from HL7 wiki) 24 This storyboard is implemented by the IHE PDQ profile. 25 One service for each document type. 24 of 56

25 RLUS Patient Service This section describes the wsdl defined for the management of a Patient Summary document represented with a HL7 R2 CDA (template CCD), using graphical and textual representation. The corresponding WSDL file is epsosrluspatientservice.wsdl Figure Patient Service WSDL (Graph) <!-- * RLUS IMPLEMENTATION --> <wsdl:definitions xmlns:wsdl=" xmlns:http=" xmlns:mime=" xmlns:soap=" xmlns:xs=" xmlns:ns="urn:rluspatient.hssp.epsos.eu" xmlns:ccd="urn:hl7-org:v3" xmlns:rlustypes="urn:rlustypes.hssp.epsos.eu" xmlns:p=" xmlns:ns2=" xmlns:ns1="urn:expression.hssp.epsos.eu" targetnamespace="urn:rluspatient.hssp.epsos.eu"> <wsdl:types> <xs:schema xmlns:ccd="urn:hl7-org:v3" xmlns:ns="urn:rluspatient.hssp.epsos.eu" attributeformdefault="qualified" elementformdefault="qualified" targetnamespace="urn:rluspatient.hssp.epsos.eu"> <xs:import namespace="urn:rlustypes.hssp.epsos.eu" schemalocation="rlustypes.xsd"/> <xs:import namespace="urn:hl7-org:v3" schemalocation="ccd.xsd"/> <!-- <xs:import namespace=" schemalocation="addressing.xsd"/> xmlns:ns1=" --> <!-- <xs:import namespace=" schemalocation="../wsa/wsbpel_serviceref.xsd"/>--> <xs:element name="getrluspatientsresponse"> Output data from the Get operation <xs:element ref="ccd:clinicaldocument" minoccurs="0"> semantic-signifier xml record <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"> 25 of 56

26 <xs:element name="putrluspatientrequest"> Input data for the Put operations <xs:element ref="ccd:clinicaldocument" minoccurs="1"> semantic-signifier xml record <xs:element ref="rlustypes:rlusputrequestsrcstruct" minoccurs="1"/> <xs:element name="writecommandenum" minoccurs="1"> Is an enumeration in WSDL / XML which is interpreted either as INSERT OR UPDATE <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="update"/> <xs:enumeration value="insert"/> </xs:restriction> </xs:simpletype> <xs:element name="discardrluspatientrequest"> Input data for the Discard operations <xs:element ref="rlustypes:rlussearchstruct" minoccurs="1"> An XML document schema for passing the semantic-signifier signifier, search and filter criteria to the semantic-signifier service. See the "Next Level" appendix section for the schema definition, XML samples and other design details regarding this parameter. <xs:element ref="rlustypes:rlusputrequestsrcstruct" minoccurs="1"> An XML document schema which contains the semantic-signifier signifier, security, source, and network address context of the caller of the Discard() operation which is necessary tracing data to clean the RLS and audit logs. <xs:element name="listrluspatientrequest"> Input data for the List operations 26 of 56

27 <xs:element ref="rlustypes:rlussearchstruct" minoccurs="1"> An XML document schema for passing the semantic-signifier signifier, search and filter criteria to the semantic-signifier service. See the "Next Level" appendix section for the schema definition, XML samples and other design details regarding this parameter. <xs:element name="maxresultstreams" type="xs:unsignedint" minoccurs="1"> Is a parameter which sets the maximum number of return calls to the List() method (i.e. max number of result sets). Such as if a value of 5 was set, then the underlying implementation would break the entire result set into 5 streams which could, for example, be represented on 5 web pages. <xs:element name="previousresultid" type="xs:string" minoccurs="1"> Is a GUID id result token which describes a cookie that the underlying implementation can use to match the caller to the underlying result set. <xs:element name="listrluspatientresponse"> Output data for List operation <xs:element ref="ccd:clinicaldocument" minoccurs="0" maxoccurs="unbounded"> Is multiple instances of an XML document which conforms to the schema for the specific semantic-signifier (such as a list of patients or orders). <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"> <xs:element name="resultid" type="xs:string" minoccurs="0"> Is the GUID id result token which describes a cookie the underlying implementation can use to match the caller to a following call to List() if the finishedflag is of 56

28 <xs:element name="finishedflag" type="xs:unsignedint" minoccurs="1"> Is a numeric identifer that returns 0 if all records in the underlying result set were packaged into a single return of the semantic-signifierxmlrecordslist. If the value is >0, then the List() operation needs to be repeatedly called to extract the rest of the result set until the flag returns 0. The numeric result specifies how many results remain. <xs:element name="locaterluspatientrequest"> Input data for the Locate operation <xs:element ref="rlustypes:rlussearchstruct" minoccurs="1"> An XML document schema for passing the semantic-signifier signifier, search and filter criteria to the semantic-signifier service. See the "Next Level" appendix section for the schema definition, XML samples and other design details regarding this parameter. <xs:element name="maxresultstreams" type="xs:unsignedint" minoccurs="1"> Is a parameter which sets the maximum number of return calls to the List() method (i.e. max number of result sets). Such as if a value of 5 was set, then the underlying implementation would break the entire result set into 5 streams which could, for example, be represented on 5 web pages. <xs:element name="previousresultid" type="xs:string" minoccurs="1"> Is a GUID id result token which describes a cookie that the underlying implementation can use to match the caller to the underlying result set. <xs:element name="locaterluspatientresponse"> 28 of 56

29 Output data for the Locate operation <xs:element ref="rlustypes:rluslocationsresultset" minoccurs="0" maxoccurs="unbounded"/> <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"> <xs:element name="resultid" type="xs:string" minoccurs="0"> Is the GUID id result token which describes a cookie the underlying implementation can use to match the caller to a following call to List() if the finishedflag is 0. <xs:element name="finishedflag" type="xs:unsignedint" minoccurs="1"> Is a numeric identifer that returns 0 if all records in the underlying result set were packaged into a single return of the semantic-signifierxmlrecordslist. If the value is >0, then the List() operation needs to be repeatedly called to extract the rest of the result set until the flag returns 0. The numeric result specifies how many results remain. <xs:element name="describerluspatientresponse"> Output data for the Describe operation <xs:element ref="rlustypes:rlussemanticsignifier"/> <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"> <xs:element name="initializerluspatientrequest"> Input data for the Initialize operation <xs:element ref="ccd:clinicaldocument" minoccurs="0"> semantic-signifier xml record <xs:element ref="rlustypes:rlusinitializerequestsrcstruct" minoccurs="1"/> <xs:element name="localrecordidsystemidpair"> 29 of 56

30 <xs:element name="localrecordid" type="xs:string"> GUID or alphanumeric ID which uniquely identifies the data representing the semantic-signifier record in the underlying local system <xs:element name="systemid" type="ccd:uuid"/> <xs:element name="findduplicatedefinitionsresponse"> <xs:element ref="ns:localrecordidsystemidpair" minoccurs="0" maxoccurs="unbounded"/> <xs:element ref="rlustypes:rlusstatuscode"> <xs:element name="sourcetargetidspair"> <xs:element name="sourcelocalrecordid" type="xs:string"/> <xs:element name="sourcesystemid" type="ccd:uuid"/> <xs:element name="targetlocalrecordid" type="xs:string"/> <xs:element name="targetsystemid" type="ccd:uuid"/> <xs:element name="semantic-signifiername" type="xs:string"/> </xs:schema> </wsdl:types> <wsdl:message name="putrequest"> <wsdl:part name="request" element="ns:putrluspatientrequest"/> <wsdl:message name="putresponse"> <wsdl:part name="response" element="rlustypes:rlusstatuscode"/> <wsdl:message name="getrequest"> <wsdl:part name="request" element="rlustypes:rlussearchstruct"/> <wsdl:message name="getresponse"> <wsdl:part name="response" element="ns:getrluspatientsresponse"/> <wsdl:message name="discardrequest"> <wsdl:part name="request" element="ns:discardrluspatientrequest"/> <wsdl:message name="discardresponse"> <wsdl:part name="response" element="rlustypes:rlusstatuscode"/> <wsdl:message name="listrequest"> <wsdl:part name="request" element="ns:listrluspatientrequest"/> <wsdl:message name="listresponse"> <wsdl:part name="response" element="ns:listrluspatientresponse"/> <wsdl:message name="locaterequest"> <wsdl:part name="request" element="ns:locaterluspatientrequest"/> <wsdl:message name="locateresponse"> <wsdl:part name="response" element="ns:locaterluspatientresponse"/> <wsdl:message name="describerequest"> <wsdl:part name="request" element="ns:semantic-signifiername"/> <wsdl:message name="describeresponse"> <wsdl:part name="response" element="ns:describerluspatientresponse"/> <wsdl:message name="initializerequest"> <wsdl:part name="request" element="ns:initializerluspatientrequest"/> <wsdl:message name="initializeresponse"> 30 of 56

31 <wsdl:part name="response" element="rlustypes:rlusstatuscode"/> <wsdl:porttype name="rluspatientserviceporttype"> <wsdl:operation name="get"> <wsdl:documentation> This is an operation for retrieving a single instance of a semantic-signifier based on parameters supplied by the XMLSearchStruct which uniquely identify a single record. A unique error code should be returned if zero or more than one record matches the filter criteria specified by the XMLSearchStruct. </wsdl:documentation> <wsdl:input message="ns:getrequest"/> <wsdl:output message="ns:getresponse"/> </wsdl:operation> <wsdl:operation name="list"> <wsdl:documentation> This operation is for returning a list of semantic-signifier instances based on the contents of the XMLSearchStruct in a manner consistent with Get() but is capable of streaming many records from the underlying source to the calling client. </wsdl:documentation> <wsdl:input message="ns:listrequest"/> <wsdl:output message="ns:listresponse"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="rluspatientservicesoapbinding" type="ns:rluspatientserviceporttype"> <soap:binding style="document" transport=" <wsdl:operation name="get"> <soap:operation soapaction="urn:get" style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="list"> <soap:operation soapaction="urn:list" style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="rluspatientservice"> <wsdl:port name="rluspatientservicesoapport" binding="ns:rluspatientservicesoapbinding"> <soap:address location=" </wsdl:port> </wsdl:service> <!-- Port type and operations --> <p:partnerlinktype name="rluspatientservicepltype"> <p:role name="rluspatientservicerole" porttype="ns:rluspatientserviceporttype"/> </p:partnerlinktype> </wsdl:definitions> Order Service This section describes the wsdl defined for the management of a Order document represented with a HL7 R2 CDA (template CCD), using graphical and textual representation. The corresponding WSDL file is epsosrlusorderservice.wsdl 31 of 56

32 Figure Order Service WSDL (Graph) <?xml version="1.0" encoding="utf-8"?> <!-- edited with XMLSpy v2009 sp1 ( by Giorgio Cangioli (.) --> <!-- * RLUS IMPLEMENTATION --> <wsdl:definitions xmlns:wsdl=" xmlns:http=" xmlns:mime=" xmlns:soap=" xmlns:xs=" xmlns:ns="urn:rlusorder.hssp.epsos.eu" xmlns:cda="urn:hl7-org:v3" xmlns:rlustypes="urn:rlustypes.hssp.epsos.eu" xmlns:pl=" xmlns:ns1=" targetnamespace="urn:rlusorder.hssp.epsos.eu"> <wsdl:types> <xs:schema attributeformdefault="qualified" elementformdefault="qualified" targetnamespace="urn:rlusorder.hssp.epsos.eu"> <xs:import namespace="urn:rlustypes.hssp.epsos.eu" schemalocation="rlustypes.xsd"/> <xs:import namespace="urn:hl7-org:v3" schemalocation="ccd.xsd"/> <!-- xs:import namespace=" --> <xs:element name="getrlusorderresponse"> Output data from the Get operation <xs:element ref="xs:any" minoccurs="0"> Is multiple instances of an XML document which conforms to the schema for the specific semantic-signifier (such as a list of patients or orders). The schema definition, XML samples and other design details regarding this parameter on a specific semantic-signifier by semantic-signifier basis is defined in "Next Level" Section 3.3 semantic-signifier Definitions for hssp Release 1.0. <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"> Output data from the CreateEntity, UpdateEntityTraitValues, RemoveEntity, LinkEntities, UnlinkEntities, MergeEntities, UnMergeEntities, InactivateEntity and ReactivateEntity service operations. Contains exception / result code from the EMPI operations. <xs:element name="putrlusorderrequest"> Input data for the Put operations <xs:element ref="xs:any" minoccurs="1"> Is multiple instances of an XML document which conforms to the schema for the 32 of 56

33 specific semantic-signifier (such as a list of patients or orders). The schema definition, XML samples and other design details regarding this parameter on a specific semantic-signifier by semantic-signifier basis is defined in "Next Level" Section 3.3 semantic-signifier Definitions for hssp Release 1.0. <xs:element ref="rlustypes:rlusputrequestsrcstruct" minoccurs="1"> An XML document schema which contains the semantic-signifier signifier, security, source, and network address context of the caller of the Discard() operation which is necessary tracing data to clean the RLS and audit logs. <xs:element name="writecommandenum" minoccurs="1"> Is an enumeration in WSDL / XML which is interpreted either as INSERT OR UPDATE <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="update"/> <xs:enumeration value="insert"/> </xs:restriction> </xs:simpletype> <xs:element name="putrlusorderresponse"> Output data for the Put operations <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"/> <xs:element name="discardrlusorderrequest"> Input data from the Discard operation <xs:element ref="rlustypes:rlussearchstruct" minoccurs="1"> An XML document schema for passing the semantic-signifier signifier, search and filter criteria to the semantic-signifier service. See the "Next Level" appendix section for the schema definition, XML samples and other design details regarding this parameter. <xs:element ref="rlustypes:rlusputrequestsrcstruct" minoccurs="1"> An XML document schema which contains the semantic-signifier signifier, security, source, and network address context of the caller of the Discard() operation which is necessary tracing data to clean the RLS and audit logs. 33 of 56

34 <xs:element name="listrlusorderrequest"> Input data for the List operations <xs:element ref="rlustypes:rlussearchstruct" minoccurs="1"> An XML document schema for passing the semantic-signifier signifier, search and filter criteria to the semantic-signifier service. See the "Next Level" appendix section for the schema definition, XML samples and other design details regarding this parameter. <xs:element name="maxresultstreams" type="xs:unsignedint" minoccurs="1"/> <xs:element name="previousresultid" type="xs:string" minoccurs="1"/> <xs:element name="listrlusorderresponse"> Outut data for the List operations <xs:element ref="xs:any" minoccurs="0" maxoccurs="unbounded"> Is multiple instances of an XML document which conforms to the schema for the specific semantic-signifier (such as a list of patients or orders). The schema definition, XML samples and other design details regarding this parameter on a specific semantic-signifier by semantic-signifier basis is defined in "Next Level" Section 3.3 semantic-signifier Definitions for hssp Release 1.0. <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"> Output data from the CreateEntity, UpdateEntityTraitValues, RemoveEntity, LinkEntities, UnlinkEntities, MergeEntities, UnMergeEntities, InactivateEntity and ReactivateEntity service operations. Contains exception / result code from the EMPI operations. <xs:element name="resultid" type="xs:string" minoccurs="0"> Is the GUID id result token which describes a cookie the underlying implementation can use to match the caller to a following call to List() if the finishedflag is 0. <xs:element name="finishedflag" type="xs:unsignedint" minoccurs="1"> Is a numeric identifer that returns 0 if all records in the underlying result set were packaged into a single return of the semantic-signifierxmlrecordslist. If the value is >0, then the List() operation needs to be repeatedly called to extract the rest of the result set until the flag returns 0. The numeric result specifies how many results remain. 34 of 56

35 <xs:element name="locaterlusorderrequest"> Input data for the Locate operations <xs:element ref="rlustypes:rlussearchstruct" minoccurs="1"> An XML document schema for passing the semantic-signifier signifier, search and filter criteria to the semantic-signifier service. See the "Next Level" appendix section for the schema definition, XML samples and other design details regarding this parameter. <xs:element name="maxresultstreams" type="xs:unsignedint" minoccurs="1"> Is a parameter which sets the maximum number of return calls to the List() method (i.e. max number of result sets). Such as if a value of 5 was set, then the underlying implementation would break the entire result set into 5 streams which could, for example, be represented on 5 web pages. <xs:element name="previousresultid" type="xs:string" minoccurs="1"> Is a GUID id result token which describes a cookie that the underlying implementation can use to match the caller to the underlying result set. <xs:element name="locaterlusorderresponse"> Output data for the Locate operations <xs:element ref="rlustypes:rluslocationsresultset" minoccurs="0" maxoccurs="unbounded"> semantic-signifier signifier name for the search in being executed <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"> Output data from the CreateEntity, UpdateEntityTraitValues, RemoveEntity, LinkEntities, UnlinkEntities, MergeEntities, UnMergeEntities, InactivateEntity and ReactivateEntity service operations. Contains exception / result code from the EMPI operations. <xs:element name="resultid" type="xs:string" minoccurs="0"> Is the GUID id result token which describes a cookie the underlying implementation can use to match the caller to a following call to List() if the finishedflag is of 56

36 <xs:element name="finishedflag" type="xs:unsignedint" minoccurs="1"> Is a numeric identifer that returns 0 if all records in the underlying result set were packaged into a single return of the semantic-signifierxmlrecordslist. If the value is >0, then the List() operation needs to be repeatedly called to extract the rest of the result set until the flag returns 0. The numeric result specifies how many results remain. <xs:element name="describerlusorderresponse"> Output data for the Describe operations <xs:element ref="rlustypes:rlussemanticsignifier" minoccurs="0"/> <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"> Is the GUID id result token which describes a cookie the underlying implementation can use to match the caller to a following call to List() if the finishedflag is 0. <xs:element name="initializerlusorderrequest"> Input data for the Initialize operations <xs:element ref="xs:any" minoccurs="0"> semantic-signifier XML record <xs:element ref="rlustypes:rlusinitializerequestsrcstruct" minoccurs="1"/> <xs:element name="cancelrlusorderrequest"> Input data for the cancel operations <xs:element name="rlusorderid" type="xs:string" minoccurs="1"> Input list of RLUSorder ID <xs:element name="detectduplicaterlusordersrequest"> 36 of 56

37 Input data for the detectduplicate operations <xs:element ref="xs:any" minoccurs="1"> semantic-signifier XML record <xs:element name="daterange" type="xs:duration" minoccurs="1"> Date range for list of episode <xs:element name="detectduplicaterlusordersresponse"> Output data for the detectduplicate operations <xs:element ref="xs:any" minoccurs="0" maxoccurs="unbounded"> semantic-signifier XML record <xs:element name="semantic-signifiername" type="xs:string"/> </xs:schema> </wsdl:types> <wsdl:message name="putrequest"> <wsdl:part name="request" element="ns:putrlusorderrequest"/> <wsdl:message name="putresponse"> <wsdl:part name="response" element="rlustypes:rlusstatuscode"/> <wsdl:message name="getrequest"> <wsdl:part name="request" element="rlustypes:rlussearchstruct"/> <wsdl:message name="getresponse"> <wsdl:part name="response" element="ns:getrlusorderresponse"/> <wsdl:message name="discardrequest"> <wsdl:part name="request" element="ns:discardrlusorderrequest"/> <wsdl:message name="discardresponse"> <wsdl:part name="response" element="rlustypes:rlusstatuscode"/> <wsdl:message name="listrequest"> <wsdl:part name="request" element="ns:listrlusorderrequest"/> <wsdl:message name="listresponse"> <wsdl:part name="response" element="ns:listrlusorderresponse"/> <wsdl:message name="locaterequest"> <wsdl:part name="request" element="ns:locaterlusorderrequest"/> <wsdl:message name="locateresponse"> <wsdl:part name="response" element="ns:locaterlusorderresponse"/> <wsdl:message name="describerequest"> <wsdl:part name="request" element="ns:semantic-signifiername"/> 37 of 56

38 <wsdl:message name="describeresponse"> <wsdl:part name="response" element="ns:describerlusorderresponse"/> <wsdl:message name="initializerequest"> <wsdl:part name="request" element="ns:initializerlusorderrequest"/> <wsdl:message name="initializeresponse"> <wsdl:part name="response" element="rlustypes:rlusstatuscode"/> <wsdl:porttype name="rlusorderporttype"> <wsdl:operation name="get"> <wsdl:input message="ns:getrequest"/> <wsdl:output message="ns:getresponse"/> </wsdl:operation> <wsdl:operation name="list"> <wsdl:input message="ns:listrequest"/> <wsdl:output message="ns:listresponse"/> </wsdl:operation> <wsdl:operation name="locate"> <wsdl:input message="ns:locaterequest"/> <wsdl:output message="ns:locateresponse"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="rlusordersoapbinding" type="ns:rlusorderporttype"> <soap:binding style="document" transport=" <wsdl:operation name="get"> <soap:operation soapaction="urn:get" style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="list"> <soap:operation soapaction="urn:list" style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="locate"> <soap:operation soapaction="urn:locate" style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="rlusorderservice"> <wsdl:port name="rlusorderserviceport" binding="ns:rlusordersoapbinding"> <soap:address location=" </wsdl:port> </wsdl:service> <pl:partnerlinktype name="rlusorderpltype"> <pl:role name="rlusorderrole" porttype="ns:rlusorderporttype"/> </pl:partnerlinktype> </wsdl:definitions> Dispension Service This section describes the wsdl defined for the management of a Dispension document represented with a HL7 R2 CDA (template CCD), using graphical and textual representation. The corresponding WSDL file is epsosrlusdispensionservice.wsdl 38 of 56

39 Figure Dispension Service WSDL (Graph) <?xml version="1.0" encoding="utf-8"?> <!-- edited with XMLSpy v2009 sp1 ( by Giorgio Cangioli (.) --> <!-- * RLUS IMPLEMENTATION --> <wsdl:definitions xmlns:wsdl=" xmlns:http=" xmlns:mime=" xmlns:soap=" xmlns:xs=" xmlns:ns="urn:rlusdispension.hssp.epsos.eu" xmlns:cda="urn:hl7-org:v3" xmlns:rlustypes="urn:rlustypes.hssp.epsos.eu" xmlns:pl=" xmlns:ns1=" targetnamespace="urn:rlusdispension.hssp.epsos.eu"> <wsdl:types> <xs:schema attributeformdefault="qualified" elementformdefault="qualified" targetnamespace="urn:rlusdispension.hssp.epsos.eu"> <xs:import namespace="urn:rlustypes.hssp.epsos.eu" schemalocation="rlustypes.xsd"/> <xs:import namespace="urn:hl7-org:v3" schemalocation="ccd.xsd"/> <!-- xs:import namespace=" --> <xs:element name="getrlusdispensionresponse"> Output data from the Get operation <xs:element ref="xs:any" minoccurs="0"> Is multiple instances of an XML document which conforms to the schema for the specific semantic-signifier (such as a list of patients or orders). The schema definition, XML samples and other design details regarding this parameter on a specific semantic-signifier by semantic-signifier basis is defined in "Next Level" Section 3.3 semantic-signifier Definitions for hssp Release 1.0. <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"> Output data from the CreateEntity, UpdateEntityTraitValues, RemoveEntity, LinkEntities, UnlinkEntities, MergeEntities, UnMergeEntities, InactivateEntity and ReactivateEntity service operations. Contains exception / result code from the EMPI operations. <xs:element name="putrlusdispensionrequest"> Input data for the Put operations <xs:element ref="xs:any" minoccurs="1"> 39 of 56

40 Is multiple instances of an XML document which conforms to the schema for the specific semantic-signifier (such as a list of patients or orders). The schema definition, XML samples and other design details regarding this parameter on a specific semantic-signifier by semantic-signifier basis is defined in "Next Level" Section 3.3 semantic-signifier Definitions for hssp Release 1.0. <xs:element ref="rlustypes:rlusputrequestsrcstruct" minoccurs="1"> An XML document schema which contains the semantic-signifier signifier, security, source, and network address context of the caller of the Discard() operation which is necessary tracing data to clean the RLS and audit logs. <xs:element name="writecommandenum" minoccurs="1"> Is an enumeration in WSDL / XML which is interpreted either as INSERT OR UPDATE <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="update"/> <xs:enumeration value="insert"/> </xs:restriction> </xs:simpletype> <xs:element name="putrlusdispensionresponse"> Output data for the Put operations <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"/> <xs:element name="discardrlusdispensionrequest"> Input data from the Discard operation <xs:element ref="rlustypes:rlussearchstruct" minoccurs="1"> An XML document schema for passing the semantic-signifier signifier, search and filter criteria to the semantic-signifier service. See the "Next Level" appendix section for the schema definition, XML samples and other design details regarding this parameter. <xs:element ref="rlustypes:rlusputrequestsrcstruct" minoccurs="1"> An XML document schema which contains the semantic-signifier signifier, security, source, and network address context of the caller of the Discard() operation which is necessary tracing data to clean the RLS and audit logs. 40 of 56

41 <xs:element name="listrlusdispensionrequest"> Input data for the List operations <xs:element ref="rlustypes:rlussearchstruct" minoccurs="1"> An XML document schema for passing the semantic-signifier signifier, search and filter criteria to the semantic-signifier service. See the "Next Level" appendix section for the schema definition, XML samples and other design details regarding this parameter. <xs:element name="maxresultstreams" type="xs:unsignedint" minoccurs="1"/> <xs:element name="previousresultid" type="xs:string" minoccurs="1"/> <xs:element name="listrlusdispensionresponse"> Outut data for the List operations <xs:element ref="xs:any" minoccurs="0" maxoccurs="unbounded"> Is multiple instances of an XML document which conforms to the schema for the specific semantic-signifier (such as a list of patients or orders). The schema definition, XML samples and other design details regarding this parameter on a specific semantic-signifier by semantic-signifier basis is defined in "Next Level" Section 3.3 semantic-signifier Definitions for hssp Release 1.0. <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"> Output data from the CreateEntity, UpdateEntityTraitValues, RemoveEntity, LinkEntities, UnlinkEntities, MergeEntities, UnMergeEntities, InactivateEntity and ReactivateEntity service operations. Contains exception / result code from the EMPI operations. <xs:element name="resultid" type="xs:string" minoccurs="0"> Is the GUID id result token which describes a cookie the underlying implementation can use to match the caller to a following call to List() if the finishedflag is 0. <xs:element name="finishedflag" type="xs:unsignedint" minoccurs="1"> Is a numeric identifer that returns 0 if all records in the underlying result set were packaged into a single return of the semantic-signifierxmlrecordslist. If the value is >0, then the List() operation needs to be repeatedly called to extract the rest of the result set until the flag returns 0. The numeric result specifies how many results remain. 41 of 56

42 <xs:element name="locaterlusdispensionrequest"> Input data for the Locate operations <xs:element ref="rlustypes:rlussearchstruct" minoccurs="1"> An XML document schema for passing the semantic-signifier signifier, search and filter criteria to the semantic-signifier service. See the "Next Level" appendix section for the schema definition, XML samples and other design details regarding this parameter. <xs:element name="maxresultstreams" type="xs:unsignedint" minoccurs="1"> Is a parameter which sets the maximum number of return calls to the List() method (i.e. max number of result sets). Such as if a value of 5 was set, then the underlying implementation would break the entire result set into 5 streams which could, for example, be represented on 5 web pages. <xs:element name="previousresultid" type="xs:string" minoccurs="1"> Is a GUID id result token which describes a cookie that the underlying implementation can use to match the caller to the underlying result set. <xs:element name="locaterlusdispensionresponse"> Output data for the Locate operations <xs:element ref="rlustypes:rluslocationsresultset" minoccurs="0" maxoccurs="unbounded"> semantic-signifier signifier name for the search in being executed <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"> Output data from the CreateEntity, UpdateEntityTraitValues, RemoveEntity, LinkEntities, UnlinkEntities, MergeEntities, UnMergeEntities, InactivateEntity and ReactivateEntity service operations. Contains exception / result code from the EMPI operations. <xs:element name="resultid" type="xs:string" minoccurs="0"> Is the GUID id result token which describes a cookie the underlying implementation can use to match the caller to a following call to List() if the finishedflag is of 56

43 <xs:element name="finishedflag" type="xs:unsignedint" minoccurs="1"> Is a numeric identifer that returns 0 if all records in the underlying result set were packaged into a single return of the semantic-signifierxmlrecordslist. If the value is >0, then the List() operation needs to be repeatedly called to extract the rest of the result set until the flag returns 0. The numeric result specifies how many results remain. <xs:element name="describerlusdispensionresponse"> Output data for the Describe operations <xs:element ref="rlustypes:rlussemanticsignifier" minoccurs="0"/> <xs:element ref="rlustypes:rlusstatuscode" minoccurs="1"> Is the GUID id result token which describes a cookie the underlying implementation can use to match the caller to a following call to List() if the finishedflag is 0. <xs:element name="initializerlusdispensionrequest"> Input data for the Initialize operations <xs:element ref="xs:any" minoccurs="0"> semantic-signifier XML record <xs:element ref="rlustypes:rlusinitializerequestsrcstruct" minoccurs="1"/> <xs:element name="cancelrlusdispensionrequest"> Input data for the cancel operations <xs:element name="rlusdispensionid" type="xs:string" minoccurs="1"> Input list of RLUSdispension ID 43 of 56

44 <xs:element name="detectduplicaterlusdispensionsrequest"> Input data for the detectduplicate operations <xs:element ref="xs:any" minoccurs="1"> semantic-signifier XML record <xs:element name="daterange" type="xs:duration" minoccurs="1"> Date range for list of episode <xs:element name="detectduplicaterlusdispensionsresponse"> Output data for the detectduplicate operations <xs:element ref="xs:any" minoccurs="0" maxoccurs="unbounded"> semantic-signifier XML record <xs:element name="semantic-signifiername" type="xs:string"/> </xs:schema> </wsdl:types> <wsdl:message name="putrequest"> <wsdl:part name="request" element="ns:putrlusdispensionrequest"/> <wsdl:message name="putresponse"> <wsdl:part name="response" element="rlustypes:rlusstatuscode"/> <wsdl:message name="getrequest"> <wsdl:part name="request" element="rlustypes:rlussearchstruct"/> <wsdl:message name="getresponse"> <wsdl:part name="response" element="ns:getrlusdispensionresponse"/> <wsdl:message name="discardrequest"> <wsdl:part name="request" element="ns:discardrlusdispensionrequest"/> <wsdl:message name="discardresponse"> <wsdl:part name="response" element="rlustypes:rlusstatuscode"/> <wsdl:message name="listrequest"> <wsdl:part name="request" element="ns:listrlusdispensionrequest"/> <wsdl:message name="listresponse"> <wsdl:part name="response" element="ns:listrlusdispensionresponse"/> <wsdl:message name="locaterequest"> <wsdl:part name="request" element="ns:locaterlusdispensionrequest"/> <wsdl:message name="locateresponse"> <wsdl:part name="response" element="ns:locaterlusdispensionresponse"/> 44 of 56

45 <wsdl:message name="describerequest"> <wsdl:part name="request" element="ns:semantic-signifiername"/> <wsdl:message name="describeresponse"> <wsdl:part name="response" element="ns:describerlusdispensionresponse"/> <wsdl:message name="initializerequest"> <wsdl:part name="request" element="ns:initializerlusdispensionrequest"/> <wsdl:message name="initializeresponse"> <wsdl:part name="response" element="rlustypes:rlusstatuscode"/> <wsdl:porttype name="rlusdispensionporttype"> <wsdl:operation name="discard"> <wsdl:input message="ns:discardrequest"/> <wsdl:output message="ns:discardresponse"/> </wsdl:operation> <wsdl:operation name="initialize"> <wsdl:input message="ns:initializerequest"/> <wsdl:output message="ns:initializeresponse"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="rlusdispensionsoapbinding" type="ns:rlusdispensionporttype"> <soap:binding style="document" transport=" <wsdl:operation name="discard"> <soap:operation soapaction="urn:discard" style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="initialize"> <soap:operation soapaction="urn:initialize" style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="rlusdispensionservice"> <wsdl:port name="rlusdispensionserviceport" binding="ns:rlusdispensionsoapbinding"> <soap:address location=" </wsdl:port> </wsdl:service> <pl:partnerlinktype name="rlusdispensionpltype"> <pl:role name="rlusdispensionrole" porttype="ns:rlusdispensionporttype"/> </pl:partnerlinktype> </wsdl:definitions> Generic RLUS Service For this service see the corresponding WSDL file: epsosrlusgeneric.wsdl Figure 5-9 RLUS generic Service WSDL (Graph) 45 of 56

46 RLUS SOAP example Inizialize Operation example inizializerequest <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv=" xmlns:xsd=" xmlns:xsi=" <soapenv:body> <wsns: InizializeRequest xmlns="urn:dispension.epsos.eu" xmlns:rlustypes="urn:rlustypes.epsos.eu" xmlns:wsns="urn:dispension.epsos.eu" xmlns:ccd="urn:hl7-org:v3"> <ccd:clinicaldocument xmlns="urn:rls.epsos.eu" xmlns:ccd="urn:hl7-org:v3" xmlns:xsi=" <!-- ******************************************************** CDA Header *******************************************************--> <ccd:typeid root=" " extension="pocd_hd000040"/> < OMISSIS> <ccd:id root="db fc99-424c-a864-7e3cda82e703"/> < OMISSIS> </ccd:clinicaldocument> <rlustypes:rlusinizializerequestsrcstruct> <rlustypes:rlussemanticsignifiername>dispension_profile</rlustypes:rlussemanticsignifier Name> <rlustypes:securitycontext> <rlustypes:sourceidentity identityname="role=pharmacist"/> </rlustypes:securitycontext> <rlustypes:cbrcontext> <rlustypes:cbrname>db fc99-494c-a864-7e3cda82e003</rlustypes:cbrname> <rlustypes:networkname>rlus_ncp1.nation1.eu</rlustypes:networkname> <rlustypes:networkaddress> </rlustypes:networkaddress> </rlustypes:cbrcontext> </rlustypes:rlusinizializerequestsrcstruct> </wsns:inizializerequest> </soapenv:body> </soapenv:envelope> inizializeresponse <soapenv:envelope xmlns:soapenv=" xmlns:xsd=" xmlns:xsi=" <soapenv:body> <?xml version="1.0" encoding="utf-8"?> <!--Sample XML file generated by XMLSpy v2009 sp1 ( <wsns:rlustypes:rlusstatuscode xsi:schemalocation="urn:rlustypes.hssp.intel.com RLUSTypes.xsd" xmlns:xsi=" xmlns:rlustypes="urn:rlustypes.hssp.intel.com"> <wsns:rlustypes:success>true</ wsns:rlustypes:success> 46 of 56

47 <wsns:rlustypes:recordid root="db fc99-424c-a864-7e3cda82e703"/> </wsns:rlustypes:rlusstatuscode> </soapenv:body> </soapenv:envelope> IS The IS WSDL example is derived from the sample Platform Dependent WSDLS for an V2 based IHE Patient Demographic Supplier Actor Profile. In that case the entity managed is the Patient Entity Role, but its representation is made with the HL7 V3 RIM instead of with ADT V2 messages. This wsdl offers 2 operations : 1. getentitytraitvalues() 2. findidentitiesbytraits() The operation getentitytraitvalues is based on Patient Registry Get Demographics Query (PRPA_IN201307UV02) HL7 V3 interaction The operation findidentitiesbytraits is based on Patient Registry Find Candidates Query (PRPA_IN201305UV02) HL7 V3 interaction (used for IHE PDQ V3 profile) In particular the element traits is modelled trough the following Message Types: Operation Description Message Type ID (from HL7 V3) getentitytraitvalues Patient Registry Get Demographics Query PRPA_MT201307UV02 getentitytraitvaluesresponse Patient Demographics PRPA_MT201303UV02.xsd findidentitiesbytraits Patient Registry Query By Demographics findidentitiesbytraitsresponse Patient Registry Find Candidates Response PRPA_MT201306UV02 PRPA_MT201310UV02) The corresponding WSDL file is epsosisqueryinterface.wsdl Here a graphical representation and the specification of the service. 47 of 56

48 Figure IS WSDL (Graph) <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions xmlns:wsdl=" xmlns:http=" xmlns:mime=" xmlns:soap=" xmlns:xs=" xmlns:ns="urn:eismgmtandqueryinterface.hssp.com" xmlns:eis="urn:eis.hssp.com" xmlns:plnk=" xmlns:v3="urn:hl7-org:v3" xmlns:ns1=" targetnamespace="urn:eis.hssp.com"> <wsdl:types> <xs:schema xmlns:v3="urn:hl7-org:v3" targetnamespace="urn:eis.hssp.com" elementformdefault="qualified" attributeformdefault="qualified" version="1.0"> <!-- Patient Registry Find Candidates Response (PRPA_HD201310UV02) --> <xs:import namespace="urn:hl7-org:v3" schemalocation="./processable/multicacheschemas/prpa_mt201310uv02.xsd"/> <!-- Patient Registry Query By Demographics (PRPA_HD201306UV02) --> <xs:import namespace="urn:hl7-org:v3" schemalocation="./processable/multicacheschemas/prpa_mt201306uv02.xsd"/> <!-- Patient Registry Get Demographics Query (PRPA_IN201307UV02) --> <xs:import namespace="urn:hl7-org:v3" schemalocation="./processable/multicacheschemas/prpa_mt201307uv02.xsd"/> <!-- Patient Registry Get Demographics Query Response (PRPA_IN201308UV02) --> <xs:import namespace="urn:hl7-org:v3" schemalocation="./processable/multicacheschemas/prpa_mt201303uv02.xsd"/> <xs:complextype name="getentitytraitvalues"> This operation is based on Patient Registry Get Demographics Query (PRPA_IN201307UV02) HL7 V3 interaction <xs:element name="entityid" type="xs:string"> GUID or alphanumeric ID which uniquely identifies the data representing the canonical record in the underlying local system 48 of 56