Download
1 / 17
170 likes | 306 Views
Joint Exchange / Interop Work Group Test Workgroup. John Donnelly. Aug 1 , 2012. Agenda. Roll Call – Admin Announcements – John Assumptions Review – Judith (35 mins ) Test Architecture – Ed (10 mins ) Definition of Done – Ed (5 mins ) Test Case Metrics – Ed (7 mins )
E N D
Joint Exchange / Interop Work Group Test Workgroup John Donnelly Aug 1, 2012
Agenda • Roll Call – Admin • Announcements – John • Assumptions Review – Judith (35 mins) • Test Architecture – Ed (10 mins) • Definition of Done – Ed (5 mins) • Test Case Metrics – Ed (7 mins) • Open Discussion – All • Wrap Up - John • Schedule Review - John
Roll • Insert Slide
Announcements • Harmonized Tests Are Drafted! • Subject to feedback • Assumptions review • Feedback needed! • If no objections received; they will be considered final • RFP • Has 5 respondents • Analysis is nearing completion • Bidder interviews likely next step for top 2 or 3
1. Consistent Terms:Patient Publish & Document Publish ISSUE “Patient records MAY be published to an SMPI using an EHR that is connected to an HIE. The HIO SHALL forward the records from its CMPI to an SMPI.” (Section 4.1.4, page 13) ------------- Is ‘The HIO’ the same actor as ‘an EHR’? IMPACT Unclear whether testing is between the first 2 actors identified or to include a third actor. ASSUMPTION ‘The HIO’ is the same actor as ‘an EHR’
2. Consistent Terms:Document Query ISSUE FR-6 Document Query: Compliance Criteria “Document request from the Initiating Gateway or local clinical application will be sent . . .” FR-6 Document Query: Normative Test Procedures “The initiating system (EHR) SHALL retrieve a list of documents . . .” ------------- Is ‘Initiating Gateway’ the same actor as ‘initiating system’? Is ‘local clinical application’ the same actor as ‘EHR’? ‘Local Clinical Application’ is not a defined term IMPACT Inconsistent use of terms make it difficult to correctly identify test actors ASSUMPTIONS ‘Initiating Gateway’ = ‘initiating system’ ‘local clinical application’ = ‘initiating system (EHR)’
3. Update Demographics & DocTRFR1-3 page 15 Testing an HIE: • Update the demographic data within the EHR for Patient #1 and add an additional document . . . • The RLS will be updated with the new document of Patient #1 Testing an EHR: • update the demographic data within the EHR for Patient #1 and add an additional document . . . • EHR shall establish a connection to the SMPI or an HIE and update the demographic data for Patient #1 . . . • EHR establish a connection to the RLS to upload the new document of Patient #1 . . . Test actors not sufficiently identified. Is this the identical test scenario, with different System Under Test? (i.e., measuring success of the EHR “send” transaction and then measuring success of the HIE “receive” – which could have been a single test scenario.)
4. Test Patient Data ISSUE “The vendor will provide patient demographics” (Section 4.1.5 page 16) “verify new document of Patient #1 “ ------------- If vendor provides test patient data, why does the test case specify a Patient #1? INTRODUCTION TO TEST PATIENT DATA
5. Patient Query:Section 4.4.4 ISSUE Verification action: • The LivingSubjectBirthTime element has been specified in the message as an exact date/time. • The LivingSubjectBirthTime element has been specified in the message as an approximate date. • The LivingSubjectBirthTime element has been specified in the message as a date range. (Page 48) ------------- Only ONE of these options is valid at a time. IMPACT These verifications should be separated by OR. ASSUMPTION Message checklists check for data type IVL_TS.
6. Patient Query:Section 4.4.4 ISSUE This test confirms the capability of: "required parameters . . . for a minimal query dataset". (Section 4.4.2) "query using all valid patient demographic combinations” (Section 4.4.4) ------------- What is the expectation for this query: minimal dataset or all demographics? IMPACT Contradictory instructions make this test scenario unclear. ASSUMPTION Harmonized test package includes test cases for both minimum required query parameters and all valid (optional) query parameters
7. Patient Query:Section 4.4.4 ISSUE Verification #3: "message shall contain a community patient id assigning authority which will only contain one root element." (page 48) ------------- What is this specifying? IMPACT LivingSubjectId/value is data type II, which contains one root and one extension. Why specify only “one root element”? ASSUMPTION The intention is to verify that AA is contained in LivingSubjectId/value @root, which is covered in the PD message checklists
8. Patient Query:Section 4.4.4 ISSUE The system should specifically be able to respond to condition code ‘204’ for unknown key identifier (page 34) This test procedure will verify the capabilities of a system to process a PIX (ITI-9) query that contains a patient id and a universal patient that do not match. (Test Step #3) ------------- Is condition code ‘204’ produced by Test Step #3 or is this a new test case? IMPACT May require new test case ASSUMPTION Condition code ‘204’ is produced by patient id and universal patient (id) that do not match. No separate test case required.
9. Test Actors ISSUE TRFR5-4: “The tester shall login in to the EHR and query the HIE for a patient by using a PDQV3 (ITI- 47) query.” (page 39) TRFR5-9: “The tester shall login in to the EHR or testing tool and query the HIE for a patient by using a PDQV3 (ITI-47) query.” (page 46) IMPACT Unclear which is the System Under Test ASSUMPTION One test is verifying ability to send, other verifies ability to receive (note “or testing tool” in one but not the other)
Architecture Review • Ed O’Connor, Nitor • Architecture Review • Definition of “done” • Metrics for Soap UI scripts
Schedule Review • RFP released — July 2nd • Questions received by 6 organizations • Answers distributed — July 13th • Bids due — July 20th • Expected award — August 15th • Contract start — TBD We are here
