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

Difference between revisions of "201601 Patient"

From HL7Wiki
Jump to navigation Jump to search
 
(12 intermediate revisions by 3 users not shown)
Line 2: Line 2:
 
[[Category:201601_FHIR_Connectathon_Track_Proposals|Jan 2016 Proposals]]
 
[[Category:201601_FHIR_Connectathon_Track_Proposals|Jan 2016 Proposals]]
 
__NOTOC__
 
__NOTOC__
=Track Name=
+
=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.
 +
 
 +
Pre-requisites: none
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
<!-- Who is asking for this track? -->
+
FHIR Management Group (FMG) in association with Patient Care (PC)
  
 
==Justification==
 
==Justification==
 
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
 
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
 +
This is the Track 1 - Patient 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 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 -->
 +
Coordinator: [mailto:bpostlethwaite@healthconnex.com.au Brian Postlethwaite]
  
 
==Expected participants==
 
==Expected participants==
 
<!-- 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 -->
 +
Unknown in this case. New participants typically make up 30% or more of Connectathon attendees.
  
 
==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 -->
===Role 1 Name===
+
===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 -->
 +
Enable the creation and retrieval of the Patient resource operations using the defined basic CRUD operations: create, history, read, search, update and delete.
  
==Steps==
+
===FHIR Server===
 +
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 +
Support the receiving and processing of the Patient resource operations: create, history, read, search and update.
 +
 
 +
==Scenarios==
 
<!-- What will be the actions performed by participants? -->
 
<!-- What will be the actions performed by participants? -->
 +
=== 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.
  
=== Track 1 - Patient ===
+
=== 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.
  
Coordinator: [mailto:david.hay25@gmail.com David Hay]
+
=== 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
  
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.
+
=== 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)
  
Pre-requisites: none
+
=== 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:
  
==== 1. Register a new patient ====
+
* [http://hl7.org/fhir/http.html/ REST API in the Spefication].
 +
* [http://hl7.org/fhir/patient.html/ Patient resource in the Spefication].
 +
* [http://fhirblog.com/2014/07/31/fhir-connectathon-7-for-java-dummies/ Java 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].
  
* Action: (Patient Demographics consumer) creates a new patient and save to Patient Service. The client can assign the Id.
+
==TestScript(s)==
* Precondition: Patient does not exist in service prior to action
+
<!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested-->
* Success Criteria: Patient created correctly on server (use browser to inspect Patient)
+
The supporting TestScripts and corresponding fixtures have been committed to the FHIR SVN repository at:
* Bonus point: The Patient resource has an extension
+
http://gforge.hl7.org/svn/fhir/trunk/connectathons/OrlandoJan2016/Connectathon11/Track1-Patient
 
 
>>Note: the requirement for the client to assign the Id has been relaxed. 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 ====
+
===TestScript Definitions===
 +
The TestScript resources in this folder represent all of the possible variations** within the tests; i.e. JSON vs. XML content, client vs. server resource id assignment, and bonus vs. no bonus features.
  
* Action: (Patient Demographics consumer) updates the patient created in scenario #1 and updates to Patient Service. The patient is retrieved by Id.
+
''**This representation of the Track 1 - Patient tests is not meant to be definitive and complete. This is one example of how these tests can be defined in the current DSTU2 format of the TestScript resource. Constructive feedback, suggestions and criticisms are welcome.''
* 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 ====
+
Based on these testing variations, the following TestScript definitions are available - one for each variation:
  
* Action: (Patient Demographics consumer) searches the patient Service for the history of a Patient
+
====FHIR Resource ID Assigned by the Client====
* Precondition:  There is a patient that has at least one update
+
* '''track1-patient-base-client-id-json''' -- JSON Format - Baseline tests to create, update, retrieve history and search a patient, no extensions with client assigned resource id.
* Success Criteria: Patient's history displayed in interface. (use browser query Patient Service)
+
* '''track1-patient-base-client-id-xml''' -- XML Format - Baseline tests to create, update, retrieve history and search a patient, no extensions with client assigned resource id.
* Bonus point: The UI allows the user to display previous versions of the Patient
+
* '''track1-patient-bonus-client-id-json''' -- JSON Format - Baseline (Bonus) tests to create, update, retrieve history and search a patient, with extensions and client assigned resource id.
 +
* '''track1-patient-bonus-client-id-xml''' -- XML Format - Baseline (Bonus) tests to create, update, retrieve history and search a patient, with extensions and client assigned resource id.
  
==== 4. Search for a patient on name ====
+
====FHIR Resource ID Assigned by the Server====
 +
* '''track1-patient-base-server-id-json''' -- JSON Format - Baseline tests to create, update, retrieve history and search a patient, no extensions with server assigned resource id.
 +
* '''track1-patient-base-server-id-xml''' -- XML Format - Baseline tests to create, update, retrieve history and search a patient, no extensions with server assigned resource id.
 +
* '''track1-patient-bonus-server-id-json''' -- JSON Format - Baseline (Bonus) tests to create, update, retrieve history and search a patient, with extensions and server assigned resource id.
 +
* '''track1-patient-bonus-server-id-xml''' -- XML Format - Baseline (Bonus) tests to create, update, retrieve history and search a patient, with extensions and server assigned resource id.
  
* Action: (Patient Demographics consumer) searches the patient Service for patients with a given name
+
===Conventions Used===
* Precondition: Patients with that name have  been created
+
The execution of the TestScript resources contained in this folder are constrained by the following conventions:
* Success Criteria: patients displayed in interface. (use browser query to confirm)
 
  
Some help links:
+
'''Fixtures''' - All resource reference values can be either url paths or local local file system paths. The convention for these TestScript resources use local file system paths where the execution engine is expected to resolve this path based on the following:
* [http://fhirblog.com/2014/07/31/fhir-connectathon-7-for-java-dummies/ Java client sample].
+
* Leading '/' character - this is resolved as an absolute path based on a known root path.
* [http://fhirblog.com/2014/06/29/c-fhir-client/ .net client sample].
+
* No leading '/' character - this is resolved as a relative path based on the location of the TestScript resource file.
 
 
 
 
===Scenario Step 1 Name===
 
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
:Precondition: <!-- What setup is required prior to executing this step? -->
 
:Success Criteria: <!-- How will the participants know if the test was successful? -->
 
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
 
 
 
<!-- Provide a description of each task
 
 
 
==TestScript(s)==
 
<!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested-->
 

Latest revision as of 21:21, 11 November 2015


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.

Pre-requisites: none

Submitting WG/Project/Implementer Group

FHIR Management Group (FMG) in association with Patient Care (PC)

Justification

This is the Track 1 - Patient 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 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

Coordinator: Brian Postlethwaite

Expected participants

Unknown in this case. New participants typically make up 30% or more of Connectathon attendees.

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 have been committed to the FHIR SVN repository at: http://gforge.hl7.org/svn/fhir/trunk/connectathons/OrlandoJan2016/Connectathon11/Track1-Patient

TestScript Definitions

The TestScript resources in this folder represent all of the possible variations** within the tests; i.e. JSON vs. XML content, client vs. server resource id assignment, and bonus vs. no bonus features.

**This representation of the Track 1 - Patient tests is not meant to be definitive and complete. This is one example of how these tests can be defined in the current DSTU2 format of the TestScript resource. Constructive feedback, suggestions and criticisms are welcome.

Based on these testing variations, the following TestScript definitions are available - one for each variation:

FHIR Resource ID Assigned by the Client

  • track1-patient-base-client-id-json -- JSON Format - Baseline tests to create, update, retrieve history and search a patient, no extensions with client assigned resource id.
  • track1-patient-base-client-id-xml -- XML Format - Baseline tests to create, update, retrieve history and search a patient, no extensions with client assigned resource id.
  • track1-patient-bonus-client-id-json -- JSON Format - Baseline (Bonus) tests to create, update, retrieve history and search a patient, with extensions and client assigned resource id.
  • track1-patient-bonus-client-id-xml -- XML Format - Baseline (Bonus) tests to create, update, retrieve history and search a patient, with extensions and client assigned resource id.

FHIR Resource ID Assigned by the Server

  • track1-patient-base-server-id-json -- JSON Format - Baseline tests to create, update, retrieve history and search a patient, no extensions with server assigned resource id.
  • track1-patient-base-server-id-xml -- XML Format - Baseline tests to create, update, retrieve history and search a patient, no extensions with server assigned resource id.
  • track1-patient-bonus-server-id-json -- JSON Format - Baseline (Bonus) tests to create, update, retrieve history and search a patient, with extensions and server assigned resource id.
  • track1-patient-bonus-server-id-xml -- XML Format - Baseline (Bonus) tests to create, update, retrieve history and search a patient, with extensions and server assigned resource id.

Conventions Used

The execution of the TestScript resources contained in this folder are constrained by the following conventions:

Fixtures - All resource reference values can be either url paths or local local file system paths. The convention for these TestScript resources use local file system paths where the execution engine is expected to resolve this path based on the following:

  • Leading '/' character - this is resolved as an absolute path based on a known root path.
  • No leading '/' character - this is resolved as a relative path based on the location of the TestScript resource file.