This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201701 Patient Track Proposal"

From HL7Wiki
Jump to navigation Jump to search
(Introduction of testing levels; Expected Participants section now lists actual participants)
Line 1: Line 1:
 
[http://wiki.hl7.org/index.php?title=Category:201701_FHIR_Connectathon_Track_Proposals Return to January 2017 Proposals]
 
[http://wiki.hl7.org/index.php?title=Category:201701_FHIR_Connectathon_Track_Proposals Return to January 2017 Proposals]
 
[[Category:201701_FHIR_Connectathon_Track_Proposals|January 2017 Proposals]]
 
[[Category:201701_FHIR_Connectathon_Track_Proposals|January 2017 Proposals]]
__NOTOC__
+
 
 
=Patient=
 
=Patient=
If creating a client, this track should require minimal work in advance of the connectathon, though at least a bit of playing is recommended. If creating a server, advanced preparation will be required, but this scenario should somewhat limit the effort involved.
+
Starting with the Connectathon 14 event this track has been selected to introduce additional levels of testing and 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 [http://build.fhir.org/http.html#capabilities 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 servers.
 +
 
 +
=== Level 2 - Mid-Level - Participants with Developed Systems ===
 +
(Level 1 +) This level provides those participants that at a minimum have been working with the FHIR specification since the last Connectathon event and have systems under active development. Automated testing is introduced and made available via the Public [http://www.fhir.org/conformance-testing FHIR Conformance Testing] platforms.
 +
 
 +
Pre-connectathon testing is highly encouraged in order to be better prepared for the actual Connectathon event. The test scenarios will be made avaiable through the public testing platforms where the [[Publicly_Available_FHIR_Servers_for_testing]] as well as other registered test systems are available.
  
Pre-requisites: TBD
+
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.
  
Step by step tutorial and sample projects: https://github.com/furore-fhir/fhirstarters
+
=== Level 3 - Experienced - Participants with (near) Production Systems ===
 +
(Level 2 +) This level introduces a more formalized testing approach for those participants that have been working the FHIR specification across multiple Connectathon events and have systems that are 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==
 
==Submitting WG/Project/Implementer Group==
Line 16: Line 36:
 
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.
  
Its purpose is to provide a way for those new to FHIR to participate using a simple scenario that can be met with limited domain knowledge, and by those who have not have 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 - no previous FHIR knowledge.
+
While this track can help the Patient resource progress along the Maturity Model, this is a secondary objective as the Patient resource has already had substantial exposure both at connectathons and in the wild.
 
 
While it can help the Patient resource progress along the Maturity Model, this is a secondary objective as the Patient resource has already had substantial exposure both at connectathons and in the wild.
 
  
 
==Proposed Track Lead==
 
==Proposed Track Lead==
 
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
 
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
 
Ron Shapiro
 
 
See [[Connectathon_Track_Lead_Responsibilities]]
 
See [[Connectathon_Track_Lead_Responsibilities]]
  
==Report==
+
Coordinator: [mailto:ron@qvera.com Ron Shapiro]
  
As this track is intended as a 'friendly introduction' to FHIR, there wasn't any real changes proposed - though it was noted that there is some ambiguity in the spec concerning the response header that should be used by the server to indicate the location of a newly created resource - this can be 'Location' or 'Content-Location' - and the client needs to check for both. A Tracked has been raised suggesting clarification.
+
Test Support: [mailto:richard.ettema@aegis.net Richard Ettema]
  
There were 17 different client/server tests, the majority of them successful. Both clients and servers were developed (or completed) on the day, and the participants felt that the event was useful for them.
+
==Expected participants==
 +
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
 +
===Level 1===
 +
*[http://wildfhir.aegis.net/fhir1-6-0 AEGIS - WildFHIR Public Test Server and Client]
 +
*Additional servers and clients
  
We did have an impromptu tutorial at the start of the event going over the basics of FHIR that was well received and maybe something that we should consider holding next time as well.
+
===Level 2===
 +
*[https://touchstone.aegis.net/touchstone AEGIS - Touchstone tool and test scripts]
 +
*[http://wildfhir.aegis.net/fhir1-6-0 AEGIS - WildFHIR Public Test Server and Client]
 +
*Additional servers and clients
  
==Expected participants==
+
===Level 3===
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
+
*[https://touchstone.aegis.net/touchstone AEGIS - Touchstone tool and test scripts]
Unknown in this case. New participants typically make up 30% or more of Connectathon attendees.
+
*[http://wildfhir.aegis.net/fhir1-6-0 AEGIS - WildFHIR Public Test Server and Client]
 +
*Additional servers and clients
  
 
==Roles==
 
==Roles==
Line 78: Line 102:
 
=== 5. Delete a patient  ===
 
=== 5. Delete a patient  ===
 
:Action: (Patient Demographics consumer) deletes the patient with a given id
 
:Action: (Patient Demographics consumer) 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.
  
Line 89: Line 113:
 
* [http://fhirblog.com/2014/06/29/c-fhir-client/ .net client sample].
 
* [http://fhirblog.com/2014/06/29/c-fhir-client/ .net client sample].
 
* [http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing Publicly Available FHIR Servers for testing].
 
* [http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing Publicly Available FHIR Servers for testing].
 +
* [https://github.com/furore-fhir/fhirstarters Step by step tutorial and sample projects].
  
 
==TestScript(s)==
 
==TestScript(s)==
 
<!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested-->
 
<!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested-->
 
The supporting TestScripts and corresponding fixtures will be committed to the FHIR SVN.
 
The supporting TestScripts and corresponding fixtures will be committed to the FHIR SVN.

Revision as of 00:42, 4 November 2016

Return to January 2017 Proposals

Patient

Starting with the Connectathon 14 event this track has been selected to introduce additional levels of testing and 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 servers.

Level 2 - Mid-Level - Participants with Developed Systems

(Level 1 +) This level provides those participants that at a minimum have been working with the FHIR specification since the last Connectathon event and have systems under active development. Automated testing is introduced and made available via the Public FHIR Conformance Testing platforms.

Pre-connectathon testing is highly encouraged in order to be better prepared for the actual Connectathon event. The test scenarios will be made avaiable through the public testing platforms where the Publicly_Available_FHIR_Servers_for_testing as well as other registered test systems are available.

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.

Level 3 - Experienced - Participants with (near) Production Systems

(Level 2 +) This level introduces a more formalized testing approach for those participants that have been working the FHIR specification across multiple Connectathon events and have systems that are 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) in association with Patient Care (PC)

Justification

This is the Patient Track testing that is included in all FHIR Connectathons.

While this track can help the Patient resource progress along the Maturity Model, this is a secondary objective as the Patient resource has already had substantial exposure both at connectathons and in the wild.

Proposed Track Lead

See Connectathon_Track_Lead_Responsibilities

Coordinator: Ron Shapiro

Test Support: Richard Ettema

Expected participants

Level 1

Level 2

Level 3

Roles

FHIR Client

Enable the creation and retrieval of the Patient resource operations using the defined basic CRUD operations: create, history, read, search, update and delete.

FHIR Server

Support the receiving and processing of the Patient resource operations: create, history, read, search and update.

Scenarios

1. Register a new patient

Action: (Patient Demographics consumer) creates a new patient and save to Patient Service. The client can assign the Id.
Precondition: Patient does not exist in service prior to action
Success Criteria: Patient created correctly on 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: (Patient Demographics consumer) updates the patient created in scenario #1 and updates to Patient Service. The patient is retrieved by Id.
Precondition: Patient has been created
Success Criteria: Patient updated on 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: (Patient Demographics consumer) searches the patient Service 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 query Patient Service)
Bonus point: The UI allows the user to display previous versions of the Patient

4. Search for a patient on name

Action: (Patient Demographics consumer) searches the patient Service 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: (Patient Demographics consumer) 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.

Help Links

Here are some links to assist implementers:

TestScript(s)

The supporting TestScripts and corresponding fixtures will be committed to the FHIR SVN.