User stories

Every paragraph describes a piece of functionality from the users' perspective. See http://en.wikipedia.org/wiki/User_story for more information.

Status
Not planned: Not yet planned in any iteration
Done: Finished, keep for reference on this page.

Pathways and flows

Status	ID	Description	Tickets
Done		Administrative: Can enroll a patient to a pathway (create a patient pathway participation). During this subscription process, the ‘participations’ flow from the pathway is triggered for this patient. The contract for the patients’ insurance company is copied to the ‘participation’ instance.	#196 Design “enroll patient to pathway” GUI (Core, closed, userstory_enroll_patient) #197 Create "enroll patient to pathway" GUI (Core, closed, userstory_enroll_patient)
Done		Developer: Create pathway plugin	#198 Define demo pathway (ZI) (Core, closed, userstory_create_pathway_plugin) #199 When an appointment is completed, throw an event. (relates to event mechanism) (Core, closed, userstory_create_pathway_plugin) #200 Create pathway domain class definition (Core, closed, userstory_create_pathway_plugin) #201 Create pathway plugin API (Core, closed, userstory_create_pathway_plugin) #202 Create demo pathway (implements pathway plugin API) (Core, closed, userstory_create_pathway_plugin)
Done		System Administrator: Deploy pathway plugin	#204 Modify OSGI bridge so pathways can be added. (Core, closed, userstory_deploy_pathway_plugin) #205 Implement hot deploy and undeploy. (Core, closed, userstory_deploy_pathway_plugin)
Done		Administrative: Can view in the patient dossier in which pathways this patient participates, ordered by start date and participated.	#206 Design pathway GUI (Core, closed, userstory_dossier_pathways) #207 Create pathway GUI (Core, closed, userstory_dossier_pathways)
Done		Administrative: Can view an overview of all pathways	#208 Design pathway overview GUI (Core, closed, userstory_pathways_overview) #209 Create pathway overview GUI (Core, closed, userstory_pathways_overview) #210 Create PathwayParticipation? DAO layer (Core, closed, userstory_pathways_overview) #211 Extend pathway service (Core, closed, userstory_pathways_overview) #212 Which workflow engine are we going to use, and why? (Core, closed, userstory_pathways_overview)

Creating a patient (merged from UseCases)

Status	ID	Description	Tickets
Done		The user can create a patient via the webinterface. This will initiate the creation of a healthrecord (in the eXist healthrecord collection), and an LDAP entity
Done		The user can create a patient using the Vecozo COVXML interface. The first idea is to enter a postal code and the birthdate, and Vecozo returns the further details. We should discuss what happens with the 'name' field, as Vecozo doesn't know the difference between first name, surname, etc. The patient data, GP details and insurance details should be fetched from Vecozo.
Done		The user can search for a patient based on the surname or the birth date. The search results link directly to the patient dossier.

Forms (merged from UseCases)

Status	ID	Description	Tickets
Done		The user can create a Form and register it for use with the HealthRecord From a architectural view, Forms can be XForms, JSP pages, Flex pages or other web served content. The registration of a form, includes the registration of a form type and the way it is opened for creation, read and update.
Not planned		Forms are only visible to users with a certain role. Creating, viewing and editing have different privileges
Done		The user can create forms in a patients’ HealthRecord. These forms are shown in a separate tab.
Done		The user can edit forms in a patients’ HealthRecord.

Appointments (merged from UseCases)

Status	ID	Description	Tickets
Done		Create an appointment with a patient. If possible this is first done with a standard ical client. At a later stage, create an appointment is added to the web interface.
Done		Add show / no-show information to appointments. Basically when a patient arrives, it needs to be registered that the patient is available.
Done		List appointments in a daily and weekly view

Agreements (merged from UseCases)

Status	ID	Description	Tickets
Not planned		Register agreements for billing. The agreement could be expressed in XML, registration of the agreement has todo with the link to parties that receives bills based on this agreement.
Not planned		Compose billable appointments to claims. Create the claim for a billable appointment based on the agreements as registered. The claim contains the amounts to be billed to the different parties.
Not planned		Process the claims and bill the parties. Depending on the type of party, the claim will go to vecozo, or send by paper to the patient (as examples). We need to find a way to separate the process of billing and the financial administration.

Health care programs

Status	ID	Description	Tickets
Not planned yet		The system administrator can create health care programs.
Not planned yet		The user can add a health care program to a patient. When a health care program is added, the referrer has to be entered. The referrer is the person who directed the patient to the clinic.
Not planned yet		The user can enter address information for a referrer. The referrer is the person who directed the patient to the clinic.

Extra information insurance companies and general practitioner

Status	ID	Description	Tickets
Not planned yet		The user should be able to enter address information (department and address details) for an insurance company. This address information should be shown in the Patient Dossier (on the patient details panel). Every insurance company must have this information. The information should consist of: recipient, street, house number, postal code, city, country
Not planned yet		The user can enter an email address for an insurance company. This address information should be shown in the Patient Dossier (on the patient details panel). The email address is optional.
Not planned yet		The user can enter an email address for a general practitioner. This address information should be shown in the Patient Dossier (on the patient details panel). The email address is optional.

Correspondence user stories

Status	ID	Description	Tickets
Not planned yet		The user can create correspondence (an email or letter), directly from the patient dossier. The correspondence is saved in the patient dossier for later reference. Correspondence can be sent to: the patient, the general practitioner, the referrer, the insurance company. Correspondence is always based on a template.
Not planned yet		The user can search correspondence from the patient dossier (search box within the correspondence tab). The content and the subject fields of the correspondence are both searched.
Not planned yet		The user can save correspondence as ‘draft’. It will not be sent, but it will be saved. In the correspondence overview it has a visual indicator that it has not been sent. At a later time, the user can continue editing and saving. Finally the user can send the correspondence.
Not planned yet		When the user clicks ‘Send’, a ‘preview’ of the content is shown, with all the variables replaced by their real values. The user can visually check the correspondence (for example if all variables are correctly filled in). In this case, the preview has an ‘Edit’ button and a ‘Send’ button.
Not planned yet		When the user clicks a letter or email in the list of correspondence in the patient dossier, the ‘preview’ of the content is shown. In this case, the preview has an ‘Close’ button, button and a ‘Send again’ button.
Not planned yet		A user can send a letter or email again. To do this, he opens an existing letter or email and clicks ‘Send again’. The piece is copied to a new correspondence item and it is opened in ‘Edit mode’. The user can change the content. After that, he clicks ‘Send’ to send the item. It ends up as a separate item in the correspondence overview.
Not planned yet		The user can create content templates on which to base correspondence. The template consists of the text of the letter. Variables can be used to fill in values when generating the final output. Something like: ${patient.birthdate} or ${patient.gender}. The *content* of the variables is not saved in the correspondence, the variable stays part of the text.
Not planned yet		The user can choose to send correspondence via ‘email’ or ‘letter’. Content templates have a property that defines if it can be sent as email, sent as letter or sent as both. Content templates contain a property who the default recipients are.
Not planned yet		The system can automatically generate correspondence based on an event. An example of an event is ‘patient dossier created’. This correspondence is generated from a template. - When a letter is automatically generated, it will be printed on a printer. There is one printer that will handle all letters. - When an email is generated, it will be sent directly to the mail address of the patient.
Not planned yet		A system administrator can configure (on runtime) which printer will be used by the system.
Not planned yet		A system administrator can configure (on runtime) the events and the actions that result from them. For example: when a new patient is created, a letter with the ‘welcome’ template must be sent to the general practitioner.
Not planned yet		The user can create correspondence for a general practitioner, directly from the patient dossier. Correspondence created this way is stored in the patient dossier.
Not planned yet		The user can create correspondence for an insurance company, directly from the patient dossier. Correspondence created this way is stored in the patient dossier.