Hey Tony,

Thats a great summary. Its good to see the reasoning behind the different contexts in which a clinician may be set.

I've addressed the different scenarios in the same order you have set out. My comments in italics.

1. Log In.
In our clinic, for right or wrong,  the log in user tends to remain the same all day. I rarely see clinicians changing it. I guess they can get away with it as the other logic (last entered clinician often makes it unecessary). Of course if they go to check their messaging they need to be logged in, as it should be :)

I have wondered if it should be possible for any user to be able to enter  a medical record/other as another user without any login? It would seem to bely the purpose of having a login option. On the other hand having to login every time you changed work station could be a pain.

But if every clincian box defaulted to the logged in user (preventing the need to ever enter a clincian field), the time saving would be so great as to overcome the nuisance value of  having to log in as you moved between work stations?

2. Medical Records
Visits and their associated medical record items (Notes, medications, documents, images, etc) each have a clinician field.

The Visit clinician is used to indicate the primary responsible clinician. When a new visit is created in Medical Records or through any workflow function it will default to the the last clinician used as per 1 above.

Each individual medical record entry also has a clinician field. This allows individual clinicians to sign the component of the medical record they contributed while still maintaining the primary responsible clinician in the Visit itself. This would be common in hospitalisation and surgery cases. Again the clinician should default to the one last used in that login as per 1.

I must confess the idea of a primary clincian that runs the visit/task does not apply in our clinic. I could imagine a referring clinician could be useful ina departmental university hospital or the like for department/user auditing. We would happily have this field hidden/removed. Can other clinics provide a context in which they use a primary clinician?

In lieu of that, as it stands, using the last entered clinician is good here.

Whilst we are talking about medical records, visits are listed in reverse chronological order. This is great. Are clinical events listed within a visit in reverse order? They weren't in 1.2. Cant remember if they are in 1.3. When we find this a problem is in very lengthy hospital visits, when visits can span several pages.

3. Billing
Both invoices and invoice items have a clinician field. These are primarily used for financial reporting purposes. Why we have both is some practices would like to report financials based on the primary clinician while others would like to break it up by the individual products and services each clinician contributed. Having the clinician in both places facilitates this.

Again both should default to the last used clinician as described in 1.

Again we don't have any use for a primary invoice clincician. Would love to have this as an optional/configurable option for location.

4. Appointments and tasks.
When adding a appointment or task the clinician field always defaults to blank even if a clinician i set for that login.

I think this is good.

You have the option of assigning a clinician which designates a request for a specific clinician in the case of an appointment or the primary clinician managing the case in the case of a task. In both schedules and work lists the clinician field can be used to filter appointments for a specific clinician. In version 1.3 it also allows you to display appointments and tasks in different colours for each clinician.

Assigning an appointment to a clinician is a good feature especially for time & motion reporting. We find the clinician color coding of limited value as we have so many clincicians. Also choosing to view as clinician means that you cant see appointment type or status colors. Our stafff seem to rarely change the highlighting option once set, and most gravitate towards Status.

Also if a clinician is designated against an appointment and you check-in that appointment to a work list the clinician will be assigned to the created task as well.

Now the important bit of information. If you set this field in an appointment or task and start any workflow function (Check-In, Consult or Check-Out) this clinician will be set as the default rather than the logged in or last used clinician as mentioned in 1. The logic is if an appointment or task is designated for a specific clinician that clinician should be set as default for all clinical record and billing data entry.

I think the logic may be valid for most out-patient events but may cause frustration and confusion with in-patient tasks where typically multiple clinicians may be entering medical records and billing information. In these cases when you initiate a consult you will see the default clinician change to that assigned to the appointment or task and be forced to change it again.

We find that rarely are appointments consulted multiple times by different clincians. With respect to worklist tasks, mutiple editing of visits is very common but we do not use "Consult" for that. We just go straigth to the patient medical records from the summary link and then edit the visit directly. Therefore this issue is not encountered alot for us.

Another issue I have found relates to medication drug label prompts initiated from billing during work flow functions . Say the last used clinician on the specific login was Dr Fred Nurk and that the appointment you are working with has no assigned clinician. When you start the consult work flow the clinician field will default to Dr Fred Nurk as mentioned above so you change it to Dr Joe Blogs. From the point you change it will remain on all subsequent clinical record and billing clinician prompts but when you get prompted for a drug label during billing it will revert back to the previous clinician. This is a bug and will be JIRA'd so gets rectified.

The other issue I found related to the Check_In process. Check-Ins generally happen at the front desk and often the reception login users are generic as each workstation can be utilised by many people. Sometimes these generic users may be classified as clinicians in order to sign additional billing items, notes etc or during check-out a specific user may change the clinician to tag their involvement for clinical or financial incentive reasons. Now based on 1 once you change a clinician it is maintained throughout the login session until changed again. This means that during check-in, when a new visit and invoice are created in preparation for consulting etc, these may both initially be tagged with this user rather than a "real" clinician. The clinicians set in the the visit and invoice do not effect subsequent clinician selection as per above rules but will effect reporting etc.

Obviously one option is the reception staff change the clinician during check-in .. another may be to set the clinician to blank during check-in and if blank during consult set them to the current clinician.

We encourage reception to set the clinician to blank.

In summary I would suggest either;

1. Making the logged in user the only clincian available and automatically selected for any new/newly edited entries (no manual clinician entry ever....).

2. Store the previous clincian entry as the default for all following contexts.

Matt C