Layout Based Transactions

sunsetsystems wrote on Tuesday, July 07, 2015:

This is a heads-up on some work I’m starting, in case it overlaps anything else going on or if anyone wants to comment.

Currently we have many different types of forms for patient activity. Some, such as for appointments, prescriptions and lab tests, are of a specific nature and are handled with specific subsystems. Others fall into these general categories:

o Visit (encounter) forms - For things that happen in the course of a visit.

o Issues - Ongoing “cases” or medical problems, which span multiple visits and often have an indefinite duration.

o Messages (patient notes) - Information structured as communication among staff members.

o Transactions - For other events or information not necessarily tied to one specific visit. Referrals are the most common example but there are also very simple transaction types named “Patient Request”, “Physician Request”, “Legal” and “Billing”.

What I’m planning is to make transactions layout-based, using the same layout engine as demographics, layout-based visit forms, etc. Referrals are already like that but we want it to be more general. This will allow new transaction types to be defined without programming.

What’s currently driving this is the need for a procedure scheduling system for specialists such as surgeons. So there will be a “Scheduled Procedure” transaction type as part of that.

Rod
http://www.sunsetsystems.com/

teryhill wrote on Tuesday, July 07, 2015:

It would be nice to have the ability to use the existing feature of conditions on all layout forms ( demographics etc.) It would also be nice to have a layout-based form for statements so it would be easier for the user to change.

sunsetsystems wrote on Tuesday, July 07, 2015:

Conditions are definitely do-able.

Statements are printer-oriented so perhaps templating somewhat like the document templates feature would work well for those. On the other hand PHP is a fine tool for templating. :slight_smile:

Rod
http://www.sunsetsystems.com/

mdsupport wrote on Tuesday, July 07, 2015:

Aren’t issues closer match for this? It already has support for codes, referrer, start(planned) & end(final procedure step) dates. Then without any coding, pt summary shows list of planned procedures and/or other actions with dates.

sunsetsystems wrote on Tuesday, July 07, 2015:

Thanks MD Support. I considered issues, but they are not a close match. For example we need time and not just date, procedure code and not just diagnosis, and about 10 other attributes not already there. The layout engine already exists and will provide the needed flexibility.

So, why not make issues layout-based? Could, but it means changing more stuff, and also issues are not events; transactions are.

Rod
http://www.sunsetsystems.com/