With OpenMRS 1.9.x we defined some custom Visit Types and Visit Attribute Types. Now using OpenMRS 2.x (with new UI) we would like to include those types somewhere. The most convenient way for us would be to just extend the “visit note” page to show our types.
Is that possible at all? And if yes, how? 
If it’s not possible on the visit note page, I would also appreciate to hear of other ways…
I would also like to know the following concerning the Visit Types and Visit Attributes Types use on the visit note page.
Note that my responses are in relation to the reference application and not OpenMRS core at wide. What are you trying to achieve?
The reference application is (currently) built around the idea of just a single VisitType, which is “Facility Visit - Patient visits the clinic/hospital (as opposed to a home visit, or telephone contact)”.
It should eventually also support (a) different types of facility visits,
and (b) non-facility visits. You’re welcome to start implementing this
support.
I would expect the visit type to be chosen at Check-In, not during Visit Note (which really just saves an Encounter).
As @wyclif says, the underlying platform supports more than this.
The reason for this is in the old UI (before upgrading to the 2.x UI) we could define Visit Attributes Type and it would appear in the visit note page when saving the encounter .
The ones maked with red is an example of an attribute type i created. My main aim is to know whether the same is still supported in the current UI.
Not sure if the screenshot explains it well but if you have any questions just ask them please. I would be glad to explain more 
I believe that Wyclif is asking for the real world use case you’re trying to achieve, to better understand the flow.
That said, the 2.x UI does not support visit attributes (yet).
Also, note that Visit Note in the 2.x UI is not the equivalent screen to the one you have shared. It is an HTML form for capturing the “consultation with clinician” part of the visit.
@wyclif The real world use case for this is to track patients and know whether its their first visit or a subsequent visit. this is because the Kenyan Government requires some diagnosis reports that show whether the patient was there for a first visit or a subsequent visit
@darius Would you know of any workaround that would be used achieve this functionality in the 2.x UI. if yes, how is it done.
As @darius mentioned, you are assuming that the visit note in 2.x is the equivalent of the Visit form in the legacy UI which is not correct. I imagine that when you click start a visit in 2.x, that is when you should capture visit attribute information e.g if it is the first or not and i think that is where you should have your feature request to get added.
My suggestion would be to create a ticket (and then do the work!) to have the Start Visit screen ask you for visit attributes.
In the 2.x. UI we will want this to be configurable so that the admin can choose which attributes are shown (e.g. some visit attributes may be behind the scenes and not shown in the UI).
@darius Sure thing… I will create a ticket.
I’ve just been looking through the code a bit to try and get an idea how to do this and I have one quick question. Is there any place where you are displaying the newer-style Attribute Types in the new UI?
Do you mean a page for adding/editing/deleting visit attribute types? If yes, not yet but we are having a sprint starting on the 27th to add pages for doing such admin tasks in the new UI. You are welcome to participate!
Note that visit attributes (like person, provider, and location attributes) exist specifically to allow implementations to extend the data model. While some visit attributes may be questions that could be asked when a visit is started, I wouldn’t expect all visit attributes to be questions that someone would/could answer when creating a visit.
Some examples of how visit attributes might be used:
Some may be known and settable by the person creating a visit; others may not be known/managed by the person creating the visit and others may be set & updated later in the visit or by external processes.
@wyclif I wasn’t referring to the admin pages to add and edit attribute types. Rather, I meant a page (or fragment) in the new UI that will render the defined attributes types.
Any updates on the above? I have a use-case where a Registration Clerk, when starting a visit in the new UI, would like to select a Visit Type (which in this case could be a drop down listing the clinics that hospital has e.g Eye Clinic, Dentist etc) where a patient is being attended to.
Any pointer on how to go about the above would be great.
I don’t think this has been worked on, did you create a ticket?
@wyclif I have created a ticket RA-977 with the description below:
I have a use-case where a Registration Clerk, when starting a Visit in the new UI, would like to select a Visit Type (which in this case could be a drop down listing the speciality clinics that the hospital has e.g Eye Clinic, Dentist etc) where a patient is being attended to.
Hi all,
We have had a use case too where our client needed to tag visits with specific visit types. See thread:
So now, we’ve developed an app to bring a set of modifications to achieve this goal.
You can find it here:
Note that it runs with Reference Application 2.2 and our own fork of Coreapps (for now) (that adds an extension point in the patient header) available on github too: Coreapps-1.6.0.1 (fork)
Hope that helps ! Thanks
@mksrom thanks for sharing! 
Do you have a pull request for adding the patient header extension point in coreapps?
@dkayiwa. Unfortunatly, it is not quite ready for pull request yet. Let me check that again and I let you know when it’s done.
