ITU-T H 830 4-2017 Conformance of ITU-T H 810 personal health system Services interface Part 4 SOAP ATNA Health & Fitness Service receiver (Study Group 16).pdf

《ITU-T H 830 4-2017 Conformance of ITU-T H 810 personal health system Services interface Part 4 SOAP ATNA Health & Fitness Service receiver (Study Group 16).pdf》由会员分享，可在线阅读，更多相关《ITU-T H 830 4-2017 Conformance of ITU-T H 810 personal health system Services interface Part 4 SOAP ATNA Health & Fitness Service receiver (Study Group 16).pdf（38页珍藏版）》请在麦多课文档分享上搜索。

1、 I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T H.830.4 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (04/2017) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS E-health multimedia services and applications Interoperability compliance testing of personal health systems (HR

2、N, PAN, LAN, TAN and WAN) Conformance of ITU-T H.810 personal health system: Services interface Part 4: SOAP/ATNA: Health Part 4: SOAP/ATNA. HFS Receiver (Version 1.7, 2017-03-14), that was developed by the Personal Connected Health Alliance. A number of versions of this specification existed before

3、 transposition. This Recommendation includes an electronic attachment with the protocol implementation conformance statements (PICS) and the protocol implementation extra information for testing (PIXIT) required for the implementation of Annex A. History Edition Recommendation Approval Study Group U

4、nique ID* 1.0 ITU-T H.834 2015-01-13 16 11.1002/1000/12252 1.0 ITU-T H.830.4 2015-01-13 16 11.1002/1000/12590 2.0 ITU-T H.830.4 2016-07-14 16 11.1002/1000/12924 3.0 ITU-T H.830.4 2017-04-13 16 11.1002/1000/13211 Keywords Conformance testing, Continua Design Guidelines, e-health, ITU-T H.810, persona

5、l connected health devices, Services interface, SOAP/ATNA, Health Part 4: SOAP/ATNA. HFS Receiver (Version 1.7, 2017-03-14), that was developed by the Personal Connected Health Alliance. The table below shows the revision history of this test specification; it may contain versions that existed befor

6、e transposition. Version Date Revision history 1.2 2012-10-05 Initial release for Test Tool DG2011. This uses “TSS users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list

7、 of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T H.810 (2016) Recommendation ITU-T H.810 (2016), Interoperability design guidelines for perso

8、nal health systems. ITU-T H.812 Recommendation ITU-T H.812 (2016), Interoperability design guidelines for personal health systems: Services interface: Common certified capability class. _ 1 This Recommendation includes an electronic attachment with the protocol implementation conformance statements

9、(PICS) and the protocol implementation extra information for testing (PIXIT) required for the implementation of Annex A. 2 Rec. ITU-T H.830.4 (04/2017) ITU-T H.812.1 Recommendation ITU-T H.812.1 (2016), Interoperability design guidelines for personal health systems: Services interface: Observation u

10、pload certified capability class. ITU-T H.812.2 Recommendation ITU-T H.812.2 (2016), Interoperability design guidelines for personal health systems: Services interface: Questionnaires certified capability class. ITU-T H.812.3 Recommendation ITU-T H.812.3 (2016), Interoperability design guidelines fo

11、r personal health systems: Services interface: Capability exchange certified capability class. ITU-T H.812.4 Recommendation ITU-T H.812.4 (2016), Interoperability design guidelines for personal health systems: Services interface: Authenticated persistent session certified capability class. IETF RFC

12、3195 IETF RFC 3195 (2001), Reliable Delivery for syslog. https:/datatracker.ietf.org/doc/rfc3195 IETF RFC 3881 IETF RFC 3881 (2004), Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications. https:/datatracker.ietf.org/doc/rfc3881 IHE ITI TF-2 IHE ITI TF 2 (2

13、010), IHE IT Infrastructure Technical Framework, Volume 2 (ITI TF-2), Revision 7.0. It comprises three sub-volumes: 2a (Transactions Part A), 2b (Transactions Part B) and 2x (Appendices). http:/ http:/ http:/ 3 Definitions 3.1 Terms defined elsewhere None. 3.2 Terms defined in this Recommendation No

14、ne. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations and acronyms: AHD Application Hosting Device ATNA Audit Trail and Node Authentication ATS Abstract Test Suite CDG Continua Design Guidelines CGM Continuous Glucose Monitor DUT Device Under Test GUI Graphical User I

15、nterface HFS Health M IHE-WSP201; M IHE-WSP202; M IHE-WSP203; M IHE-WSP205; M IHE-WSP206; M IHE-WSP207; M IHE-WSP208; M IHE-WSP211; M IHE-WSP212; M IHE-WSP300; M IHE-WSA101; M Test purpose Check that: Table V.2.4-1 lists XML namespaces that are used in this appendix. AND IHE requires the profile wri

16、ters and recommends the implementors to use the following naming convention for WSDL artifacts: - message request - Transaction Name_Message - message response - Transaction Name_Response_Message - portType - NAME_PortType - Operation - NAME_Transaction Name_OperationID - SOAP 1.2 binding - NAME_Bin

17、ding_Soap12 - SOAP 1.2 port - NAME_Port_Soap12 AND The targetNamespace of the example WSDL shall be urn:ihe:DOMAIN:PROFILE:YEAR and may be extended to urn:ihe:DOMAIN:PROFILE:YEAR:TYPE AND The WSDL shall include XML Schema Definition references for the transactions payloads. AND Two WSDL messages sha

18、ll be defined for a request-response transaction AND In the example WSDL provided by an IHE specification a single WSDL part named Body shall be defined for each WSDL message and the part type shall refer to an element defined in the Schema Definition required in IHE-WSP203 AND For each input and ou

19、tput message defined in the WSDL portType operation an attribute wsaw:Action shall be included AND WSDL operations shall use wsdl:operation/wsdl:input/wasw:Action = “urn:ihe:Domain:Year:Transaction name“ and wsdl:operation/wsdl:output/wsaw:Action = “urn:ihe:Domain:Year:Transaction nameResponse“ AND

20、For each operation defined in the WSDL portType a wsoap:operation/soapAction attribute shall be provided. The value of wsoap:operation/soapAction shall be consistent with the name for the corresponding WSDL operation defined in the WSDL portType AND The WSDL provided with an IHE specification shall

21、use the SOAP Binding described in WSDL 1.1 Chapter 3 and the binding extension for SOAP 1.2 AND 10 Rec. ITU-T H.830.4 (04/2017) All elements shall have the mustUnderstand attribute set (mustUnderstand=1) Applicability C_REC_000 AND C_REC_GEN_003 Other PICS Initial condition The HFS receiver under te

22、st has a WebService published and the simulated HFS sender is ready to send a SOAP message. Test procedure 1. The simulated HFS sender takes the WSDL description of the WebService provided by the HFS receiver and checks: a. Namespaces: wsdl: “http:/schemas.xmlsoap.org/wsdl/“ soap12: “http:/schemas.x

23、mlsoap.org/wsdl/soap12“ xsd: “http:/www.w3.org/2001/XMLSchema“ wsaw: “http:/www.w3.org/2006/05/addressing/wsdl“ b. WSDL artifacts: message request - Transaction Name_Message message response - Transaction Name_Response_Message portType - NAME_PortType Operation - NAME_Transaction Name_OperationID SO

24、AP 1.2 binding - NAME_Binding_Soap12 SOAP 1.2 port - NAME_Port_Soap12 where NAME is the value of the /wsdl:definitions/name attribute and Transaction Name represents the formal IHE transaction name for this particular web-service exchange with spaces omitted from the name. c. The targetNamespace is

25、urn:ihe:DOMAIN:PROFILE:YEAR and can be extended to urn:ihe:DOMAIN:PROFILE:YEAR:TYPE d. Two WSDL messages are defined, one for the request transaction and another for the response transaction. e. A single WSDL part named Body is defined for each WSDL message and the part type refers to an element def

26、ined in the schema definition included in the xsd reference. f. For each input and output message defined in the WSDL portType operation an attribute wsaw:Action is included and: wsdl:operation/wsdl:input/wsaw:Action = “urn:ihe:Domain:Year:Transaction name“ wsdl:operation/wsdl:output/wsaw:Action = “

27、urn:ihe:Domain:Year:Transaction nameResponse“ g. For each operation defined in the WSDL portType a wsoap:operation/soapAction attribute is provided and its value is consistent with the name for the corresponding WSDL operation defined in the WSDL portType h. WSDL provided with an IHE specification u

28、ses the binding extension for SOAP 1.2 2. The simulated HFS sender sends a SOAP message to the HFS receiver using addressing header blocks. 3. The HFS receiver responds with another SOAP message. Check that all elements have the mustUnderstand attribute set (mustUnderstand=1 ir true) Pass/Fail crite

29、ria In step 1, all elements are in the WSDL description. In step 3, the response messages are as specified. Notes Rec. ITU-T H.830.4 (04/2017) 11 TP Id TP/HFS/REC/SOAP/HEAD/BV-001 TP label Security Guidelines Coverage Spec ITU-T H.812 Testable items CommonReq 4; M SecGuidelines 1; M SecGuidelines 4;

30、 M Test purpose Check that: All Continua HFS connections shall be initiated from the HFS client component and shall not be initiated from the HFS service component. AND Continua HFS client and service components shall support the TLS protocol v1.0 (RFC 2246) from WS-I BSP v1.0 for secure communicati

31、on AND Continua HFS client and service components shall support transfer of entity assertion information via SAML 2.0 token through WS-Security Header according to the Web Services Security: SAML Token Profile 1.1 Applicability C_REC_000 AND C_REC_GEN_003 Other PICS Initial condition The HFS receive

32、r under test has a WebService published and the simulated HFS sender is ready to establish a connection using TLS b-IETF RFC 2246 and SAML 2.0 as an authentication token b-OASIS SAMLTP. Test procedure 1. The simulated HFS sender starts a connection with the HFS receiver using HTTP over TLS v1.0. 2.

33、The HFS receiver under test allows the connection. 3. The HFS sender sends a message using an SAML 2.0 token as an authentication token. 4. The HFS receiver accepts the token and responds to the message without a security error. Pass/Fail criteria All steps are as specified above. If the HFS receive

34、r responds with an error in step 4, it shall not be provoked by security reasons. Notes TP Id TP/HFS/REC/SOAP/HEAD/BV-002 TP label HFS Observation Receiver Requirements Coverage Spec ITU-T H.812.1 Testable items ReceiverReq 2; M ReceiverReq 3; M Test purpose Check that: A Continua HFS service compon

35、ent shall support WS-ReliableMessaging as an RM Destination for CommunicatePCDDataResponse messages AND A Continua HFS service component shall support WS-ReliableMessaging as an RM Source for CommunicatePCDDataResponse messages Applicability C_REC_000 AND C_REC_GEN_003 Other PICS Initial condition T

36、he simulated HFS sender is using WS-RM and the HFS receiver under test are in a none sequence state. Test procedure 1. The simulated HFS sender sends a CreateSequence message to the HFS receiver 12 Rec. ITU-T H.830.4 (04/2017) with an offer element. 2. The HFS receiver under test responds with Creat

37、eSequenceResponse or with CreateSequenceRefused. 3. If the sequence created is not refused, the simulated HFS sender sends an HL7 message within the soap body of a sequence message indicating that it is the last one. 4. The HFS receiver responds with a SequenceAck header block message, a sequence he

38、ader block and an HL7 message in the body. 5. The simulated HFS sender sends a SequenceAcknowledgement. Pass/Fail criteria All steps are as specified above. Notes The HFS receiver acts as an RM source in step 4 and as an RM destination in the other steps. A.3 Subgroup 2.3.1: ATNA general (GEN) TP Id

39、 TP/HFS/REC/ATNA/GEN/BV-006 TP label Reliable Syslog ATNA Actor behaviour Coverage Spec IHE ITI TF-2 Testable items Audit_MT-1; M Test purpose Check that: If the Audit Record repository is not available, the HFS actor shall store the audit record in a local buffer until the audit record repository i

40、s available again. Applicability C_REC_000 AND C_REC_GEN_001 AND C_REC_ATNA_001 Other PICS C_REC_GEN_003, C_REC_GEN_004 Initial condition The HFS receiver under test is shutdown. The simulated HFS sender has a SOAP message (a PCD-01 message or a consent document) ready to be sent and the Simulated A

41、udit Repository with Reliable Syslog transport is intentionally disabled. Test procedure 1. The HFS receiver application under test is started and it sends the corresponding audit record message to the audit repository. As the simulated audit repository receiver is disabled, the message will not be

42、delivered. 2. Wait for one minute. 3. The test tool starts the simulated audit repository. 4. If C_REC_GEN_002 = FALSE (the SUT does not support consent management) THEN the simulated HFS sender sends a PCD-01 message to the HFS receiver under test. IF C_REC_GEN_002 = TRUE (the SUT supports consent

43、management) THEN the simulated HFS sender sends a consent document to the HFS receiver under test. 5. The test tool receives the SOAP message (a PCD-01 message or a consent document) acknowledge and the audit record messages sent by the HFS receiver under test. Pass/Fail criteria Two audit record me

44、ssages must be received by the simulated audit repository: One for the HFS receiver start action (step 1) and the other for the SOAP message sent in step 4. There is one audit record with the attribute “code“ of the element EventID set to “110107“ (PHI-import) and the EventDateTime attribute of the

45、EventIdentification element is set to the expedition time of the SOAP message sent in step 4. There is one audit record with the attribute “code“ of the element EventID set to “110120“ (start action) and the EventDateTime attribute of the EventIdentification element is set at least one minute before

46、 the expedition time of the SOAP message sent in step 4. Notes In step 4, the way to force the HFS receiver to send the pending audit record not delivered in step 1 depends on the vendor implementation. A typical strategy could be to send Rec. ITU-T H.830.4 (04/2017) 13 another HFS message and its c

47、orresponding ATNA record; in this way, when the HFS receiver under test sends the ATNA record PHI-import, then it would send the pending audit record along with the newer one. A.4 Subgroup 2.3.2: ATNA PCD-01 (PCD-01) TP Id TP/HFS/REC/ATNA/PCD-01/BV-000 TP label PCD-01 - Reliable Syslog ATNA Actor St

48、art Coverage Spec IHE ITI TF-2 Testable items AuditMess-2; R AuditMess-3; M ActTrans-8; O ActTrans-6; O ATNA_IP-2; O ATNA_PF-1; M ChainTrust-2; M DirectCert-1; M DirectCert-2; M DirectCert-3; M Trigg_Event-1; M Audit_RF-1; M Rel_Syslog-1; M Rel_Syslog-2; M Spec ITU-T H.812 Testable items SecGuidelines 3; O Spec IETF RFC 3881 Testable items SAAAM-DD-01; M SAAAM-DD-02; O SAAAM-DD-03; M SAAAM-DD-04; M SAAAM-DD-05; O SAAAM-DD-06; M SAAAM-DD