Requirement Constraints

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Tuesday, 11 December 2012

EMR Appointment Features

Posted on 09:43 by Unknown

Let me list the most common features in the Appointment module and their priority using MoSCoW Method.

MoSCoW Method

M - MUST:
Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.

S - SHOULD:
Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

C - COULD:
Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.

W - WON'T:
Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

Feature 1

The system should provide the option of quickly registering a patient before booking an appointment without going full walk through of patient registration screen.

Use case

Patient is mandatory while booking an appointment. But for a new patient want to book appointment, then user should be able to create the patient in the system with the minimal information quickly and then use for the appointment booking.

MoSCoW

Must


Feature 2

The system should provide the option to view appointments as daily view, Weekly view and Monthly view

Use case

Practice often want to see how many appointments for a week by provider

MoSCoW

Must


Feature 3

The system should provide the option to schedule appointment for people or resource

Use case

Schedule Providers, Nurses, PAs and Schedule Resources – rooms, equipment, etc.

MoSCoW

Must


 

Feature 4

Audit Trail for each Appointment.

Use case

Often user will make more noise if someone modify or cancelled the existing appointments.
Each appointment should be under the audit trail. The audit information should show the following information

  1. Who and When the appointment is created.
  2. Who and When the appointment is modified and what they have modified (old value and new value)
  3. Who and when and why the appointment is deleted.
  4. Who and When and why the appointment is cancelled.

MoSCoW

Must

 

Feature 5

Report. The solution should provide the following on the Appointment Report Module

  1. Print Appointment Lists by day by each resource or all resource.
  2. Print Cancellation Summary by Week or by Month.
  3. Print No Show Summary by Week or By Month
  4. Print Super bill of the practice for the appointment by day or by week.

Use case

Use case is quite self-explanatory.

MoSCoW

Must

 

Feature 6

The Solution should allow appointments to be scheduled in various increments i.e., 15, 30 or 45 minutes, based on reason of visit.

Use case

Even though resource default slot time interval can be fixed, but for some appointment type, doctor may need more time apart from the default interval. Usually it will multiple of N times of default Time interval. Say for example, resource default time interval is 15 min, but at the time of appointment booking for appointment reason, the resource may need 30 min. So system should have the option extend the end time at the appointment level.

MoSCoW

Must

 

Feature 7

The Solution should notify the booking staff that patient has missed previous appointments.

Use case

In some of the practice, as a procedure, they will not allow further appointments for the patient if there are too many no shows in the past. If there are too many no shows, then it will be revenue loss for the doctor.

By showing this alert, user can take a call to avoid appointment booking or they can charge small amount on the patient for the previous missed appointments.

MoSCoW

Should



Feature 8

The Solution should have the ability to display all past and future appointments by a patient in chronological order.

Use case

This will help the users to cancel or analyze about the patient appointments.

MoSCoW

Should


Feature 9

Mark Appointments as Cancelled or No-Show. Very importantly, system should capture the reason when cancelling the appointment

Use case

This will help the user to cancel the appointment upon patient request.

MoSCoW

Should



Feature 10

Mark Appointments as deleted due to data entry error. Very Importantly, system should capture the reason when deleting the appointment and also it should be soft delete.

Use case

This will help the user to delete the appointment due to data entry error.

MoSCoW

Should

 

Feature 11

Allow overbooking (waiting list) for a given slot according resource preferences

Use case

This will help to user to create the appointment as waiting list for a particular slot according to resource preference(allow 1 or 2 or 3 waiting list for me). This way resource can utilize the time slot if someone is no Show.

MoSCoW

Should




Feature 12

Automatically updates pending appointments based on changes made to patient status (deceased or deactivated).

Use case

Use case is quite self-explanatory. On action, the system should inform the user it is going to move all the appointments to cancelled status with automated cancelled reason.

MoSCoW

Should



Feature 13

Block Times for Non-patient Activities.(i.e. lunch, Meetings, etc.). Should support recurrence pattern by Daily, Weekly, Monthly and yearly.

Use case

Use case is quite self-explanatory.

MoSCoW

Should



Feature 14

User Defined Colors for Coding Appointments Status. The solution should provide this setting by practice, can be overridden by resource and can be overridden by appointment if necessary.

Use case

Use case is quite self-explanatory.

MoSCoW

Should



Feature 15

Cut and Paste Appointments.

Use case

The Cut and Paste features of the Scheduler allow you to move selected appointment(s) to different time slots and/or schedules.

MoSCoW

Should





Feature 16

Duplicate Appointment Alert. When scheduling an appointment for a patient, system should alert the user if the particular patient already have an appointment schedule for the same date , for the same resource or for the different resource.

Use case

Use case is quite self-explanatory.

MoSCoW

Should



Feature 17

Move an appointment from one provider to another provider.

Use case

This feature is can be achieved if Cut and Past appointments is available (Feature No 16)

MoSCoW

Should

 

Feature 18

Reschedule an appointment without deleting or cancelling the appointment.

Use case

This feature is can be achieved if Cut and Past appointments is available (Feature No 16)

MoSCoW

Should


Feature 19

Appointment Remainder Service via email . The email reminders are automatically set to be sent out one week prior to a scheduled appt, and then also one day prior.

Use case

Use case is quite self-explanatory.

MoSCoW

Should

 

Feature 20

User Defined Colors for Coding Appointments type or reason. The solution should provide this setting by practice, can be overridden by resource and can be overridden by appointment if necessary.

Use case

Use case is quite self-explanatory.

MoSCoW

Should

 

Feature 21

Move an appointment in a series to a different service provider or Move an entire series of appointments to a different service provider

Use case

This will help the user to switch appointment resource if the particular resource moved out of the practice.

MoSCoW

Could




Feature 22

Block all the resource scheduler in the practice for the Holidays. This is similar to Feature 14, but there should be way to do the same action for all the available resource in the practice.

Use case

Use case is quite self-explanatory.

MoSCoW

Could



Feature 23

The system should provide the option creating appointments for non-providers such as Nurses, Lab, X-Ray, etc

Use case

Use case is quite self-explanatory.

MoSCoW

Could

 

Feature 24

Patients With Upcoming Appointments... When scheduling a patient, the system should popup if patient has upcoming appointments if any. Just count can be shown, on clicking of the count, appointment list details can be shown.

Use case

Use case is quite self-explanatory.

MoSCoW

Could



Feature 25

Generates patient instructions when booking particular appointments which can be printed as part of the appointment notification for the patient.

Use case

This will help particularly for the Test Visit. There might be some instructions for the patient be prepared before taking any test. http://labtestsonline.org/understanding/features/test-prep/.

Normally each practice will maintain the test instruction for some lab test. That will be given to the patient at the time of check out or at the appointment booking.

MoSCoW

Could



Feature 26

Change / cancel one appointment in a series without changing / cancelling the others.

Use case

This will help the user to change or cancel one appointment in a series (Created using Feature 4) without touching the other appointments belong in the same series. For example, for the post surgery follow up visit, patient may want to cancel one of the appointment due to unavailability.

MoSCoW

Could



Feature 27

Ability to book a series of appointments based on a care plan.e.g. Monthly appointments for pregnancy checks. e.g. Quarterly appointments for Diabetic patients.To do this, Solution should have the ability of searching free slot in the future for the given provider, preferred start and end time, etc..

Use case

This will help the user to book series of appointments in one click, instead of going each date and each slot and again and again select the same patient.  Additionally, the user can give a name for the series of the appointment created, so then for any future reference, they can pull all the appointments by giving the name of the series.

MoSCoW

Could



Feature 28

The Solution should have the ability Schedule Appointments with Single or Multiple Resources. (e.g. exam rooms, X-Ray machine, etc.)

Use case

This will help the patient to complete all type of visits in the same day. Here is an example;

Doctor order an X-Ray for the patient which can be taken within the practice itself.

So here there are two appointments; one with the test technician who will handle the Lab and after the X-Ray has been taken , the doctor has to review and Change the Notes.

So if the solution has the feature of booking appointment for multiple resource consecutively, then it will help the patient to meet the doctor on the same date after Lab part is over.

MoSCoW

Could

Read More
Posted in EMR Appointment Features | No comments
Newer Posts Older Posts Home
Subscribe to: Posts (Atom)

Popular Posts

  • ZK Example for inline Editing with Add New and Delete
    I am quite impressed on this demo from ZK . But adding new record and delete existing record is missing as part of typical CRUD. So i thoug...
  • EDI 5010 Documentation 837 Professional - Loop 2010BB Payer Name
    2010BB Payer Name          In this loop, all the information will be taken from Insurance master screen. Take a look of our sample screen...
  • EDI 5010 Documentation–837 - BHT - Beginning of Hierarchical Transaction
    BHT – Beginning of Hierarchical Transaction Loop Seg ID Segment Name Format Length Ref# Req Value   BHT Beginning of Hier...
  • Hibernate Validator Example 2
    In this example, we will see some more validation constraints such as @email, @past, @length, etc. And also we will also define custom error...
  • ZK Passing Parameter between two files using MVVM–Part 1
    Overview This is the first series of articles about Passing parameter between two zul files using MVVM Design pattern .This article will fo...
  • MVVM Command annotation and Notify change example
    Here is an example, how to pass parameter on a zul through MVVM Command binding annotation. ZK URL http://books.zkoss.org/wiki/ZK%20Develo...
  • History of Present Illness
    HPI - One of the main component of Clinical History. What is an HPI ? The history of present illness (HPI) is a chronological description...
  • Patient Demographics
    Patient browse (search) is the key element for any EMR / PMS Software. In my past 15 years experience, i involved more than 5 times in desig...
  • ViewModel Class Java Annotation @Init, @NotifyChange, @Command
    In following sections we'll list all syntaxes that can be used in implementing a ViewModel and applying ZK bind annotation. The ZK binde...
  • Good Website Design Links
    Form Design Label Placement in Forms International Address Fields in Web Forms 40 Eye-Catching Registration Pages blog-comment-form-...

Categories

  • Billing Process
  • C Workbook
  • C++ Workbook
  • Eclipse Tips
  • EDI 5010
  • EMR Appointment Features
  • EMR Labs Stuff
  • EMR PMS Links
  • EMR Use cases
  • EMR Vital Sign
  • Good Website Design
  • Hibernate Criteria Queries
  • Hibernate Introduction
  • Hibernate Introduction Setup
  • Hibernate Mapping
  • Hibernate POC
  • Hibernate Validator
  • Hibernate–Java Environment setup
  • HPI
  • Java
  • Maven
  • MU Certification
  • NPI
  • PQRS
  • Practice Management System
  • Spring Security
  • Tech Links
  • Today Tech Stuff
  • zk
  • ZK Hibernate
  • ZK 5 Databinding
  • ZK Application
  • ZK Calling Another ZUL
  • ZK CheckBox
  • ZK CreateComponents
  • ZK CSS
  • ZK extended Components
  • ZK Foreach
  • ZK Forum Posts
  • ZK Framework
  • ZK Hibernate Setup
  • ZK ID Space
  • ZK Include
  • ZK Installation
  • ZK iReport
  • ZK Layout
  • ZK Listitem Pagination
  • ZK Message Box
  • ZK MVC
  • ZK MVC Combox Box
  • ZK MVC CRUD Examples
  • ZK MVC Listbox
  • ZK MVVM
  • ZK MVVM Combo
  • ZK MVVM CRUD
  • ZK MVVM ListBox
  • ZK Spring
  • ZK TextBox

Blog Archive

  • ►  2013 (105)
    • ►  December (3)
    • ►  September (7)
    • ►  August (13)
    • ►  July (1)
    • ►  June (11)
    • ►  May (3)
    • ►  April (14)
    • ►  March (19)
    • ►  February (21)
    • ►  January (13)
  • ▼  2012 (177)
    • ▼  December (1)
      • EMR Appointment Features
    • ►  November (13)
    • ►  October (19)
    • ►  September (24)
    • ►  August (26)
    • ►  July (6)
    • ►  June (37)
    • ►  May (30)
    • ►  April (16)
    • ►  March (1)
    • ►  January (4)
  • ►  2011 (5)
    • ►  December (1)
    • ►  November (1)
    • ►  July (1)
    • ►  June (1)
    • ►  April (1)
  • ►  2010 (1)
    • ►  September (1)
Powered by Blogger.

About Me

Unknown
View my complete profile