This wiki has undergone a migration to Confluence found Here

Difference between revisions of "201601 Patient"

From HL7Wiki
Jump to navigation Jump to search
(Re-structured the information based on the proposal sections)
Line 3: Line 3:
 
__NOTOC__
 
__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.
 +
 +
Pre-requisites: none
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
This track is included in all Connectathons
+
FHIR Management Group (FMG)
  
 
==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.
  
 
==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:david.hay25@gmail.com David Hay]
  
 
==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 -->
 +
The expected participants are those attending a Connectathon for the first time and returning participants who wish to support this track for themselves and others.
  
 
==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 -->
 +
Support the sending of the Patient resource operations: create, history, read, search and update.
 +
 
 +
===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 -->
 +
Support the receiving and processing of the Patient resource operations: create, history, read, search and update.
  
 
==Steps==
 
==Steps==
 
<!-- 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.
=== Track 1 - Patient ===
+
:Precondition: Patient does not exist in service prior to action
 
+
:Success Criteria: Patient created correctly on server (use browser to inspect Patient)
Coordinator: [mailto:david.hay25@gmail.com David Hay]
+
:Bonus point: The Patient resource has an extension
 
 
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
 
 
 
 
 
==== 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 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.
 
>>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 ====
+
=== 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.
  
* Action: (Patient Demographics consumer) updates the patient created in scenario #1 and updates to Patient Service. The patient is retrieved by Id.
+
=== 3. Retrieve Patient history ===
* Precondition: Patient has been created
+
:Action: (Patient Demographics consumer) searches the patient Service for the history of a Patient
* Success Criteria: Patient updated on server (use browser to inspect Patient)
+
:Precondition: There is a patient that has at least one update
* Bonus Point #1: Update a patient that has extensions, but leaving the extension untouched.
+
:Success Criteria: Patient's history displayed in interface. (use browser query Patient Service)
* Bonus Point #2: Update a patient that has extensions, and update the extension also.
+
:Bonus point: The UI allows the user to display previous versions of the Patient
  
==== 3. Retrieve Patient history ====
+
=== 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)
  
* Action: (Patient Demographics consumer) searches the patient Service for the history of a Patient
+
==Help Links==
* Precondition:  There is a patient that has at least one update
+
Here are some helpful links to assist implementers:
* 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)
 
 
 
Some help links:
 
 
* [http://fhirblog.com/2014/07/31/fhir-connectathon-7-for-java-dummies/ Java client sample].
 
* [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://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].
 
 
===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)==
 
==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-->

Revision as of 15:53, 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)

Justification

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

Proposed Track Lead

Coordinator: David Hay

Expected participants

The expected participants are those attending a Connectathon for the first time and returning participants who wish to support this track for themselves and others.

Roles

FHIR Client

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

FHIR Server

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

Steps

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 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

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)

Help Links

Here are some helpful links to assist implementers:

TestScript(s)