I’m using appointment scheduling, and I need to relate appointment_types to providers. What I want to achieve is a way I can directly get appointment types(or medical specialties) which a provider can do.
In this moment, for what I understand from the database model, we just associate both them through an appointment block, and that’s not enough for me.
I was thinking about use Provider attribute type, as a way to do it, using a CustomDatatype (ex: AppointmentTypeCustomDatatype), receiving a list of AppointmentType, on this attribute.
What do you think? Is this a good approach? Or do you think it’s preferrable to add a new relation table to the database model?
Hi @dkayiwa, it could be a way to go, however I would prefer to keep it in a more typified way. Is it possible to create a custom data type, in a form of List? I’m not sure if it makes sense.
If I follow your comma separated sugestion, I just need a String provider attribute type, isn’t it?
@fmalmeida, what is the change you’re planning to make, as seen from the end-user perspective? Where is the medical specialty supposed to be displayed? When assigning a provider to an appointment block? When making an appointment for a patient?
@darius, I want to make a bulk insert of providers schedule. It would allow users to create the availability schedule faster, since appointment schedule ui, don’t allow, at least now, to repeat schedules, what turns it unusable.
So, I would like to have this relation between providers and their appointment types, so that way I would add their availability in all of their types for a given day and hour.
I know it doesn’t fit all implementations, but for my requirements it could be a transition feature.
So as I understand it this data need not be displayed in the UI, it’s just to drive your scripting of a bulk insert.
You could use the Provider Management module which introduces a providermanagement_provider_role table and adds a provider_role_id column to the core provider table.
The Provider Management module does a lot more than this (I’m not sure what, honestly), but we include it in the Reference Application purely for this limited purpose.
Otherwise, using a provider attribute type as you’ve suggested does make sense.
Thanks @darius, but I don’t really like the idea, I prefer the provider attribute type. I think it’s cleaner and more intuitive to understand.
I’ll choose the provider attribute type, with a comma separated string as suggested before.
But for future reference, do I need to develop CumtomDataType, CustomHandler and CustomWidget classes, so I can use AppointmentTypes, as an input for my provider attribute type?
If you’re not using these in the UI, you only need a CustomDatatype. (And I would suggest you go ahead and build that now, instead of of doing comma-separated strings.)
The handler and widget classes are for the UI, and you’d need to write those if you’re expecting a UI to automatically handle them. (But, I’m not sure the UI you’re using will actually handle this.)
@darius, I’m a bit confused, but without handler and widget, how can I associate provider to an appointment type(since ??legacyui?? creates the widget of the attribute on provider creation/edition page)? Do I have to “deploy” this data, from a data deployer module? I don’t have any problem with the deployer module solution, is just to be sure if I understood it well.