Difference between revisions of "201701 Patient Track Proposal"
m (Updated headers in Scenarios section) |
Ron Shapiro (talk | contribs) |
||
| Line 3: | Line 3: | ||
=Patient= | =Patient= | ||
| − | Starting with the Connectathon 14 event this track | + | Starting with the Connectathon 14 event in San Antonio this track will include additional levels of testing including a more formalized reporting of test results. |
===Pre-Requisites=== | ===Pre-Requisites=== | ||
| Line 13: | Line 13: | ||
Pre-connectathon testing is encouraged, but not required, where the participants can utilize the existing [[Publicly_Available_FHIR_Servers_for_testing]]. | Pre-connectathon testing is encouraged, but not required, where the participants can utilize the existing [[Publicly_Available_FHIR_Servers_for_testing]]. | ||
| − | Testing and test reporting at the Connectathon event will be self-attested using the Results tab of the Tracking Spreadsheet (link TBD) and primarily involve peer-to-peer execution between known FHIR clients and servers. | + | Testing and test reporting at the Connectathon event will be self-attested using the Results tab of the Tracking Spreadsheet (link TBD) and primarily involve peer-to-peer execution between known FHIR clients and/or servers. |
=== Level 2 - Formal Testing - Participants with FHIR experience === | === Level 2 - Formal Testing - Participants with FHIR experience === | ||
| Line 23: | Line 23: | ||
==Submitting WG/Project/Implementer Group== | ==Submitting WG/Project/Implementer Group== | ||
| − | FHIR Management Group (FMG | + | FHIR Management Group (FMG) |
==Justification== | ==Justification== | ||
| Line 29: | Line 29: | ||
This is the Patient Track testing that is included in all FHIR Connectathons. | This is the Patient Track testing that is included in all FHIR Connectathons. | ||
| − | + | This track provides new participants with a friendly introduction to FHIR, using a simple scenario that can be met with limited domain knowledge and by those who have not had a lot of exposure to FHIR. | |
==Proposed Track Lead== | ==Proposed Track Lead== | ||
| Line 42: | Line 42: | ||
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track --> | <!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track --> | ||
===Level 1=== | ===Level 1=== | ||
| + | *Many of the new participants which typically make up 30% or more of Connectathon attendees. | ||
*[https://touchstone.aegis.net/touchstone AEGIS - Touchstone tool and test scripts] (optional) | *[https://touchstone.aegis.net/touchstone AEGIS - Touchstone tool and test scripts] (optional) | ||
*[http://wildfhir.aegis.net/fhir1-6-0 AEGIS - WildFHIR Public Test Server and Client] | *[http://wildfhir.aegis.net/fhir1-6-0 AEGIS - WildFHIR Public Test Server and Client] | ||
| Line 57: | Line 58: | ||
==Roles== | ==Roles== | ||
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> | <!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> | ||
| − | ===FHIR Client | + | |
| + | ===FHIR Client=== | ||
<!-- Provide a description of the capabilities this role will have within the connectathon --> | <!-- Provide a description of the capabilities this role will have within the connectathon --> | ||
This actor initiates the processing requests that enable the creation, deletion, manipulation and retrieval of Patient resource instances. The required, supported interactions are the defined basic CRUD operations: create, read, update and delete. Additional required, supported interactions are the operations: vread, history and search. | This actor initiates the processing requests that enable the creation, deletion, manipulation and retrieval of Patient resource instances. The required, supported interactions are the defined basic CRUD operations: create, read, update and delete. Additional required, supported interactions are the operations: vread, history and search. | ||
| Line 63: | Line 65: | ||
(Example FHIR Client CapabilityStatement here) | (Example FHIR Client CapabilityStatement here) | ||
| − | ===FHIR Server | + | ===FHIR Server=== |
<!-- Provide a description of the capabilities this role will have within the connectathon --> | <!-- Provide a description of the capabilities this role will have within the connectathon --> | ||
| − | This actor | + | This actor receives, processes and responds to the requests for creation, deletion, manipulation and retrieval of Patient resource instances. The implementation of this actor would normally provide for a repository storage mechanism along with corresponding maintenance and retrieval capabilities of the Patient resource instances. The required, supported interactions are the defined basic CRUD operations: create, read, update and delete. Additional required, supported interactions are the operations: vread, history and search. |
(Example FHIR Server CapabilityStatement here) | (Example FHIR Server CapabilityStatement here) | ||
| Line 72: | Line 74: | ||
<!-- What will be the actions performed by participants? --> | <!-- What will be the actions performed by participants? --> | ||
=== Level 1 - Introduction - New Participants/Systems === | === Level 1 - Introduction - New Participants/Systems === | ||
| − | '''The following scenarios represent the basic scenarios that participants will work to implement during the Connectathon event. Execution of these scenarios is expected to be performed with the other participants of this track as well as the [[Publicly_Available_FHIR_Servers_for_testing]]. | + | '''The following scenarios represent the basic scenarios that participants will work to implement during the Connectathon event. Execution of these scenarios is expected to be performed with the other participants of this track as well as the [[Publicly_Available_FHIR_Servers_for_testing]]. |
==== 1. Register a new patient ==== | ==== 1. Register a new patient ==== | ||
| − | :Action: | + | :Action: FHIR client creates a new patient and save to FHIR server. The client can assign the Id. |
| − | :Precondition: Patient does not exist in | + | :Precondition: Patient does not exist in FHIR server prior to action |
| − | :Success Criteria: Patient created correctly on server (use browser to inspect Patient) | + | :Success Criteria: Patient created correctly on FHIR server (use browser to inspect Patient) |
:Bonus point: The Patient resource has an extension | :Bonus point: The Patient resource has an extension | ||
| Line 83: | Line 85: | ||
==== 2. Update a patient ==== | ==== 2. Update a patient ==== | ||
| − | :Action: | + | :Action: FHIR client updates the patient created in scenario #1 and updates to FHIR server. The patient is retrieved by Id. |
:Precondition: Patient has been created | :Precondition: Patient has been created | ||
| − | :Success Criteria: Patient updated on server (use browser to inspect Patient) | + | :Success Criteria: Patient updated on FHIR server (use browser to inspect Patient) |
:Bonus Point #1: Update a patient that has extensions, but leaving the extension untouched. | :Bonus Point #1: Update a patient that has extensions, but leaving the extension untouched. | ||
:Bonus Point #2: Update a patient that has extensions, and update the extension also. | :Bonus Point #2: Update a patient that has extensions, and update the extension also. | ||
==== 3. Retrieve Patient history ==== | ==== 3. Retrieve Patient history ==== | ||
| − | :Action: | + | :Action: FHIR client searches the FHIR server for the history of a Patient |
:Precondition: There is a patient that has at least one update | :Precondition: There is a patient that has at least one update | ||
| − | :Success Criteria: Patient's history displayed in interface. (use browser query | + | :Success Criteria: Patient's history displayed in interface. (use browser to query FHIR server) |
:Bonus point: The UI allows the user to display previous versions of the Patient | :Bonus point: The UI allows the user to display previous versions of the Patient | ||
==== 4. Search for a patient on name ==== | ==== 4. Search for a patient on name ==== | ||
| − | :Action: | + | :Action: FHIR client searches the FHIR server for patients with a given name |
:Precondition: Patients with that name have been created | :Precondition: Patients with that name have been created | ||
:Success Criteria: patients displayed in interface. (use browser query to confirm) | :Success Criteria: patients displayed in interface. (use browser query to confirm) | ||
==== 5. Delete a patient ==== | ==== 5. Delete a patient ==== | ||
| − | :Action: | + | :Action: FHIR client deletes the patient with a given id |
:Precondition: a Patients with that Id has been created | :Precondition: a Patients with that Id has been created | ||
:Success Criteria: Subsequently querying for the patient - either searching by name or by Id - fails. | :Success Criteria: Subsequently querying for the patient - either searching by name or by Id - fails. | ||
=== Level 2 - Formal Testing - Participants with FHIR experience === | === Level 2 - Formal Testing - Participants with FHIR experience === | ||
| − | '''The following scenarios represent the formal testing scenarios that participants have been working to implement both prior to and during the Connectathon event. Execution of these scenarios will focus on automated testing with the public testing platforms and is expected to be performed with the other participants of this track as well as the [[Publicly_Available_FHIR_Servers_for_testing]]. Each of the scenarios are implemented as FHIR | + | '''The following scenarios represent the formal testing scenarios that participants have been working to implement both prior to and during the Connectathon event. Execution of these scenarios will focus on automated testing with the public testing platforms and is expected to be performed with the other participants of this track as well as the [[Publicly_Available_FHIR_Servers_for_testing]]. Each of the scenarios are implemented as FHIR TestScript resources that include extensive assertions to provide a more comprehensive validation/verification of the systems under test conformance to the FHIR specification.''' |
==== 1. Patient Registration/Creation ==== | ==== 1. Patient Registration/Creation ==== | ||
Revision as of 16:23, 6 December 2016
Return to January 2017 Proposals
Contents
- 1 Patient
- 1.1 Pre-Requisites
- 1.2 Level 1 - Introduction - New Participants/Systems
- 1.3 Level 2 - Formal Testing - Participants with FHIR experience
- 1.4 Submitting WG/Project/Implementer Group
- 1.5 Justification
- 1.6 Proposed Track Lead
- 1.7 Expected participants
- 1.8 Roles
- 1.9 Scenarios
- 1.10 Help Links
- 1.11 TestScript(s)
Patient
Starting with the Connectathon 14 event in San Antonio this track will include additional levels of testing including a more formalized reporting of test results.
Pre-Requisites
For all levels of testing the required pre-requisite is the fundamental requirement that all FHIR servers SHALL support the capabilities interaction.
Level 1 - Introduction - New Participants/Systems
This has been and will remain the primary purpose of this track and provides a 'friendly introduction' for those new to FHIR. Attendees participate in this track using a simple scenario that can be met with limited domain knowledge and by those who have not had a lot of exposure to FHIR. It is quite feasible to complete the client side of the track within a day with only knowledge of a development environment and little to no previous FHIR knowledge. If creating a server, advanced preparation will be required, but this scenario should somewhat limit the effort involved.
Pre-connectathon testing is encouraged, but not required, where the participants can utilize the existing Publicly_Available_FHIR_Servers_for_testing.
Testing and test reporting at the Connectathon event will be self-attested using the Results tab of the Tracking Spreadsheet (link TBD) and primarily involve peer-to-peer execution between known FHIR clients and/or servers.
Level 2 - Formal Testing - Participants with FHIR experience
(Level 1 +) This level introduces a more formalized testing approach for those participants that have been working the FHIR specification for one or more Connectathon events and have systems that are in active development, or deployed or soon to be deployed into a production environment. Automated testing is significantly leveraged for both automated testing (testing tool to FHIR server) and surveliance of peer-to-peer testing (external FHIR client to external FHIR server).
Pre-connectathon testing is highly encouraged in order to be better prepared for the actual Connectathon event and become familiar with the public testing platforms that will be used for the formal testing.
Testing and test reporting will be done using the public testing platforms which will provide test results via the new FHIR TestReport resource type as well as any specific reporting capabilities of those testing platforms. These reports will provide qualitative and quantitative analysis of the system under test and its conformance to the FHIR specification.
Submitting WG/Project/Implementer Group
FHIR Management Group (FMG)
Justification
This is the Patient Track testing that is included in all FHIR Connectathons.
This track provides new participants with a friendly introduction to FHIR, using a simple scenario that can be met with limited domain knowledge and by those who have not had a lot of exposure to FHIR.
Proposed Track Lead
See Connectathon_Track_Lead_Responsibilities
Coordinator: Ron Shapiro
Test Support: Richard Ettema
Expected participants
Level 1
- Many of the new participants which typically make up 30% or more of Connectathon attendees.
- AEGIS - Touchstone tool and test scripts (optional)
- AEGIS - WildFHIR Public Test Server and Client
- Additional participants
See Tracking Spreadsheet (link TBD)
Level 2
- AEGIS - Touchstone tool and test scripts
- AEGIS - WildFHIR Public Test Server and Client
- Additional participants
See Tracking Spreadsheet (link TBD)
Roles
FHIR Client
This actor initiates the processing requests that enable the creation, deletion, manipulation and retrieval of Patient resource instances. The required, supported interactions are the defined basic CRUD operations: create, read, update and delete. Additional required, supported interactions are the operations: vread, history and search.
(Example FHIR Client CapabilityStatement here)
FHIR Server
This actor receives, processes and responds to the requests for creation, deletion, manipulation and retrieval of Patient resource instances. The implementation of this actor would normally provide for a repository storage mechanism along with corresponding maintenance and retrieval capabilities of the Patient resource instances. The required, supported interactions are the defined basic CRUD operations: create, read, update and delete. Additional required, supported interactions are the operations: vread, history and search.
(Example FHIR Server CapabilityStatement here)
Scenarios
Level 1 - Introduction - New Participants/Systems
The following scenarios represent the basic scenarios that participants will work to implement during the Connectathon event. Execution of these scenarios is expected to be performed with the other participants of this track as well as the Publicly_Available_FHIR_Servers_for_testing.
1. Register a new patient
- Action: FHIR client creates a new patient and save to FHIR server. The client can assign the Id.
- Precondition: Patient does not exist in FHIR server prior to action
- Success Criteria: Patient created correctly on FHIR server (use browser to inspect Patient)
- Bonus point: The Patient resource has an extension
>>Note: the resource Id can either be created by the client or the server (depending on the capability of the server). However, if the server assigns the Id, then the client will need to be able to retrieve the Id from the server response or by a patient query.
2. Update a patient
- Action: FHIR client updates the patient created in scenario #1 and updates to FHIR server. The patient is retrieved by Id.
- Precondition: Patient has been created
- Success Criteria: Patient updated on FHIR server (use browser to inspect Patient)
- Bonus Point #1: Update a patient that has extensions, but leaving the extension untouched.
- Bonus Point #2: Update a patient that has extensions, and update the extension also.
3. Retrieve Patient history
- Action: FHIR client searches the FHIR server for the history of a Patient
- Precondition: There is a patient that has at least one update
- Success Criteria: Patient's history displayed in interface. (use browser to query FHIR server)
- Bonus point: The UI allows the user to display previous versions of the Patient
4. Search for a patient on name
- Action: FHIR client searches the FHIR server for patients with a given name
- Precondition: Patients with that name have been created
- Success Criteria: patients displayed in interface. (use browser query to confirm)
5. Delete a patient
- Action: FHIR client deletes the patient with a given id
- Precondition: a Patients with that Id has been created
- Success Criteria: Subsequently querying for the patient - either searching by name or by Id - fails.
Level 2 - Formal Testing - Participants with FHIR experience
The following scenarios represent the formal testing scenarios that participants have been working to implement both prior to and during the Connectathon event. Execution of these scenarios will focus on automated testing with the public testing platforms and is expected to be performed with the other participants of this track as well as the Publicly_Available_FHIR_Servers_for_testing. Each of the scenarios are implemented as FHIR TestScript resources that include extensive assertions to provide a more comprehensive validation/verification of the systems under test conformance to the FHIR specification.
1. Patient Registration/Creation
(Steps go here)
2. Patient Modification/Update
(Steps go here)
3. Patient History and Version Read
(Steps go here)
4. Patient Searching via Multiple Criteria
(Steps go here)
5. Patient Deletion/Removal
(Steps go here)
Help Links
Here are some links to assist implementers:
- REST API in the Specification.
- Patient resource in the Specification.
- Open_Source_FHIR_implementations.
- Publicly Available FHIR Servers for testing.
- Step by step tutorial and sample projects.
TestScript(s)
The supporting TestScripts and corresponding fixtures will be committed to the FHIR SVN.
