Milestone #1 Discussion

[aethelwulffe]

This issue addresses general conversation, assignment of issues, and other communications related to the milestone that are not directly applicable to a single issue.

[aethelwulffe]

Closed Login screen issue: I would like to see this go further eventually. I would like to see us add a LibreEHR/LibreHealth news feed (toggle?) on the login screen. I feel this would satisfy a long-needed connection to our users.

While I approve of a centered login applet, the styling is still too old-school to be considered fresh and new to me. The native patient portal looks a little bit better.

[aethelwulffe]

Should we start another issue related to actual bugs/unimplemented features related to the Frameless feature? We will need a punchlist I think, not sure if Styling is completely related.

[tmccormi]

We should not be shy to add issues for discussion at anytime

[tmccormi]

So to consolidate the general milestone discussion in this issue item is a good for now. I didn't know Art added this. good idea.

Issue #3 and #17 might be duplicates unless we hold #3 for supplimental tools and changes to the default install (which default to JSON, I believe).

[aethelwulffe]

Agreed. Maybe looking at milestone No.2, but: I think I need a separate (set?) of issues dealing with some basic billing behavior. Live data is showing the following: Billing adjustment codes are not handled very well. Some denial codes are not getting flagged in red on the html batch reports. It is possible for an insurance company to add codes to your fee sheet. These get added as CPT4 even when they are HCPCS. Directly entering an ICD10 code, especially sequential diagnosis, will cause gen_837 to use the BK flag instead of ABK, indicating that they are ICD-9. I commented out the ICD9 check and they submit properly. It is possible for insurance companies to completely dork up your accounting by submitting long strings of "gonna pay, haven't paid" credits and debits ad-nausea. This sometimes results in several dozen useless and messy entries for one claim line item, and bones the heck out of the quality of reporting.

[tmccormi]

How much of the @teryhill pull requests are related to #2

[aethelwulffe]

I will review those requests and see about tagging them. On another subject, has anyone seen anything ever posted on securing admin.php? I think it would be wonderful if the base installation required some sort of login to access that page, as well as getting some from/return URL's passed to sql_upgrade and the like to ensure direct access is not happening. This would make a lot of folks happier, and I could see adding something like this to a list pretty soon.

[tmccormi]

It needs to be secured. No one have ever done that. Really I think it should just be part of the base login to check for version change and updates. Then ONLY allow admin to login and do them. Specifically I mean the admin is the only login ALLOWED until the updates have been done.

[tmccormi]

Time to see where we are. Would be nice to release version 1 this week (close to planned)

[aethelwulffe]

I cleared a few issues, and move a couple to Milestone#2...which isn't actually called Milestone#2. Version 1.0.0 won't be what I could have hoped, but I prefer to have things move on and get re-scheduled rather than sit unattended and stale.

[tmccormi]

I had not created milestone 2 yet... Cause a date is needed and aren't ready to pick that yet

Tony McCormick

On Aug 4, 2016 1:43 PM, "Art Eaton" notifications@github.com wrote:

I cleared a few issues, and move a couple to Milestone#2...which isn't actually called Milestone#2. Version 1.0.0 won't be what I could have hoped, but I prefer to have things move on and get re-scheduled rather than sit unattended and stale.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LibreEHR/LibreEHR/issues/7#issuecomment-237677423, or mute the thread https://github.com/notifications/unsubscribe-auth/AARci_jZJRerA3KquRU_ZLXXmbFrLBO3ks5qck7SgaJpZM4JOBZo .

Please be aware that e-mail communication can be intercepted in transmission or misdirected. Please consider communicating any sensitive information by telephone. The information contained in this message may be privileged and confidential. If you are NOT the intended recipient, please notify the sender immediately with a copy to hipaa-security@mrsb-ltd.com and destroy this message.

[tmccormi]

We are having a great time with slash and burn ... but are we focused on MileStone 1.0.0 release issues or adding more and more.

[tmccormi]

Milestone target - 22% complete 7 open 2 closed

[tmccormi]

I'm entertained by Ubuntu's release names ... our 1.0.0 is clearly being referred to as "Slash and Burn"

[aethelwulffe]

Yeah, we have been going with that. Ubuntu would be "Thresher Shark". Eventually we would need "Fhir Beetle". We could stick to tool names for a while though. Like "Machete". "Fine-Toothed Chainsaw", "Scalpel", "Bulldozer", etc..

[aethelwulffe]

Eventually we will need a "Redstone Update".

[aethelwulffe]

Commented on the now closed issue and commits concerning the removal of phpmyadmin.

[aethelwulffe]

Oh, I see you mostly addressed that bit.

[tmccormi]

Down to 3 that are really open.

[aethelwulffe]

Zend, Menu, and that review.
What is the prognosis on each for the milestone?

[tmccormi]

1. Zend ready for review
2. Menu no change except formatting the menu_data.php, needs more and some documentation at least
3. I think we are done with the "good stuff" for this release

[tmccormi]

There are a couple more slash and burn issues we could consider. And install from source instructions, I think.

[tmccormi]

You can't vote using reaction on four things in the same comment .... They have to be separated

[aethelwulffe]

Reaction smaction. Was thinking narrative. Fine. Changing.

[aethelwulffe]

VOTE: Add menu admin.

[aethelwulffe]

VOTE: Remove excess forms.

[aethelwulffe]

VOTE: Re-label most menu items, completely re-organize menu.

[aethelwulffe]

VOTE: Dump (possibly all) contribs forms including CAMOS.

[aethelwulffe]

VOTE: Slash and burn on contents of database, including ripping out tables, setting default collation, set default engine, remove excess fields from heavy use tables like calendar, patient data etc, testing for hard-coded field names. LOOK HARD at empty tables and fields in production databases.

[aethelwulffe]

VOTE: Spin up a new repo for add-on reports, utilities, and intervention forms

[tmccormi]

Questions:

1. Define "Excess Forms' for who? General Practice, Eye Docs, Mental Health?
2. Relabel reorg menu items? in what way based on what? How many different medical practices have been surveyed and what types?

[tmccormi]

Slash and burn on contents of database - I'd say this is too much for milestone 1.0 release

[aethelwulffe]

1. • Keeping the base package as sparse as possible* I would minimize to a single ROS (that should be configurable), the better and most integrated of the vitals forms, dump CAMOS, seriously consider if SOAP should be there in it's current form (some academics hate the concept, and it does not lead to structured data when the PLAN is crammed into one of many forms), and lay the groundwork for people being able to easily include things like an ankle injury form while keeping the base package as sparse as possible. That is why I mention it. Sparse.
     1. Menu items need a lot of help. The Administration tab is one. There is (with current styling) no visible separator between items, and having a single sub menu in the middle of a long string is not very handy.
   • "Visits" should be named "Encounters" everywhere. This is a major point of confusion for many people. Appointments and Encounter, not appointments visits and encounters.
   • Most reports have very weak naming.
   • Patients/Patients is stupid.
   • New/Search is often use wrong (at least at first) because of how it is named.
   • "FEES" should be named "Billing"
   • "Billing" should be named "Billing Manager".
   • "Posting" and "Batch Payments" are confusing as all hell.
   • Under a "Billing" tab, most of the practice management people's reports should be in a sub-menu there.
   • Patient/Client probably should have the tags stuff in there for the people that have access to it. Same sort of thing for a lot of other admin stuff. ...I could go on in this vein for a few hours. The current issue is that this is not being done very cleverly. The menu structure is used too much as a way of constructing the ACL. The items should be under a heading that matches a job type, and the ACL should simply restrict what they see out of those items. Why two address book entries? It should be under "communications" or "contacts" sub-menu or something in a place it makes sense...not in one particular menu because that is where super-user only stuff goes.

[aethelwulffe]

Not hardlining ...or anything like it, but if we are calling this a new product, then, well, it think it should feel newer and more convenient. We never really see eye-to-eye when it comes to my trunk->branch view of organizing things.

[tmccormi]

On Wed, Aug 17, 2016 at 4:25 PM, Art Eaton notifications@github.com wrote:

1.

• Keeping the base package as sparse as possible* I would minimize to a single ROS (that should be configurable), the better and most integrated of the vitals forms, dump CAMOS, seriously consider if SOAP should be there in it's current form (some academics hate the concept, and it does not lead to structured data when the PLAN is crammed into one of many forms), and lay the groundwork for people being able to easily include things like an ankle injury form while keeping the base package as sparse as possible. That is why I mention it. Sparse.

LBF allows the creation of any kind of simple form by the end user. I don't think most of the coded forms add any value to that. Expections are Vitals and the Graphic Pain Map (soon to be extended)...

1.

1. Menu items need a lot of help. The Administration tab is one. There is (with current styling) no visible separator between items, and having a single sub menu in the middle of a long string is not very handy.

Styling needs are understood

1. 1.

• "Visits" should be named "Encounters" everywhere. This is a major point of confusion for many people. Appointments and Encounter, not appointments visits and encounters.

Language module allows that to be remapped per the users desire. Agree that the baseline should be one or the other not both

• Most reports have very weak naming.

Yes

• Patients/Patients is stupid.

Yes

• New/Search is often use wrong (at least at first) because of how it is named.

Yes

• "FEES" should be named "Billing"

yes

• "Billing" should be named "Billing Manager".

yes

• "Posting" and "Batch Payments" are confusing as all hell.

Hmmm. where is Posting? I sure some refinement between Batch Payment Posting, EOB Payment posting overlap and Patient payment posting could be managed.

• Under a "Billing" tab, most of the practice management people's reports should be in a sub-menu there.
• Patient/Client probably should have the tags stuff in there for the people that have access to it. Same sort of thing for a lot of other admin stuff. ...I could go on in this vein for a few hours. The current issue is that this is not being done very cleverly. The menu structure is used too much as a way of constructing the ACL. The items should be under a heading that matches a job type, and the ACL should simply restrict what they see out of those items.

I agree.

• Why two address book entries? It should be under "communications" or "contacts" sub-menu or something in a place it makes sense...not in one particular menu because that is where super-user only stuff goes.

Agree with that entirely

Tony

Please be aware that e-mail communication can be intercepted in transmission or misdirected. Please consider communicating any sensitive information by telephone. The information contained in this message may be privileged and confidential. If you are NOT the intended recipient, please notify the sender immediately with a copy to hipaa-security@mrsb-ltd.com and destroy this message.

[tmccormi]

What do people think (In terms of menu item access style) of the Hit a MENU Button and just start typing and get a ajax generated list of what seems to match your request (and permissions?) Ubuntu has that and so does Windows a bit. I kind of like it, most of the time.

[aethelwulffe]

I could go for a "search menu" thing, but not at the expense of a presented menu. People that know what is there will know where to find it, and folks that don't, well they don't know what it is called, that it exists, or what it is for. That is where a clean menu tree with good names helps. For instance, you have some experience with this application. You are not sure about the "Posting" thing. Neither are billers that have worked with it for a mere few months. That is bad. :japanese_ogre:

[tmccormi]

... You are not sure about the "Posting" thing

That's more reflective of there being 3 (or more) ways to post payments than the menu organization.. Certainly anyone with accounting training knows what Posting means .. :-)

[aethelwulffe]

Just a question of which one to use and when... Thus the uuuhhh...errrrrrr...which I experience each time I am getting back into using the stuff or trying to train someone. I can't actually remember the catches between using one or the other for one thing or the other, and when it is safe to use "Payments" or "Checkout" for stuff either. I have to screw a few things up, then figure it out, then fix the screw-ups. I DO however have a high awareness that it is messed up and goofy. Not having any illusions that it should "just work" is quite a large advantage, and thus shows me to be excellently trained.

On 2016-08-18 12:43 PM, Tony McCormick wrote:

... You are not sure about the "Posting" thing

That's more reflective of there being 3 (or more) ways to post payments than the menu organization.. Certainly anyone with accounting training knows what Posting means .. :-)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/LibreEHR/LibreEHR/issues/7#issuecomment-240783416, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhzFwqtrdM12Qmerixoh7z2J4NzRrq4ks5qhIvDgaJpZM4JOBZo.

[aethelwulffe]

Down to menu, graphics (maybe links) and one sql bug fix for final testing on milestone1. A couple of other issues that may be closable, and this one...which can be taken off the milestone itself.

[aethelwulffe]

Discussion please: List each of your demands for a release date. Mine:

1. All the little EHR thingies open up, and all the little thinglets inside the thingies do something when clicked.
2. As much trash and bugs (live and dead) have been taken to the curb.
3. We have a reasonable distribution and deployment method.

[tmccormi]

There are no more issues open that are assigned to Milestone 1 Release except creating a distribution.

Should I create an issue called RELEASE and start the process of branching and tagging? Do we need some install instructions for "build from source"?

[aethelwulffe]

I do have a distribution issue posted, and I am working on the windows package side of that, but I think no particular distribution package need to be a precursor to a release version. I am pretty damn sure the reverse is true. It is too much work to make a totally clean package until you have a release. That said, let's make that RELEASE 1.0.0-r issue, find that distribution file server, and get the build/deploy instructions posted so I can work them into a document, someone can put them in a wiki or support forum thing, and load up a readme.

[aethelwulffe]

Release version Demo server Distributions with documentation Launch announcement. -just my note list.

[tmccormi]

My list: Flowboard issues, all.

[aethelwulffe]

I think that is a given. That flowboard is pacemaker for the very weak heart (PN calendar). Any problems with it, and everything will have issues.

[tmccormi]

I don't show any new issues for the release. If there are going to be additional issues please create them or assign them to Milestone 1

[aethelwulffe]

I am not doing anything else on Milestone for 1.0 release version of the code. The next chronological milestone is for DISTRIBUTION to my mind. I believe we agree that the flowboard issues are (or should be)assigned to this and nothing else. As to any of the outstanding pull requests, if we are sitting on those and not snuffing them, fine, but the release has to happen.

[tmccormi]

OK, let's do that, and code freeze today. No new merges except critical bugs with 3 thumbs up and the flowboard tickets.

[teryhill]

I don't have any thing to add for the release. 

  From: Art Eaton <notifications@github.com>

To: LibreEHR/LibreEHR LibreEHR@noreply.github.com Cc: Terry Hill teryhill@yahoo.com; Mention mention@noreply.github.com Sent: Monday, September 12, 2016 3:49 PM Subject: Re: [LibreEHR/LibreEHR] Milestone #1 Discussion (#7)

I am not doing anything else on Milestone for 1.0 release version of the code. The next chronological milestone is for DISTRIBUTION to my mind. I believe we agree that the flowboard issues are (or should be)assigned to this and nothing else. As to any of the outstanding pull requests, if we are sitting on those and not snuffing them, fine, but the release has to happen.— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.