A client has a need to be able to review incoming documents similarly to incoming lab results. That is, to add a Review Status attribute to documents and to list the unreviewed ones for a given date range and look at them and mark them as reviewed. Signing not required.
Now this looks a bit like the Lab Documents menu item and report added by Ensoftek last year for MU2. Except there’s no review status stuff.
So, two questions:
Can I start enhancing the Lab Documents page without messing up MU2 certification? Or do I need to create my own?
I see that documents have a field audit_master_approval_status, courtesy of ZH. This seems to be related to Care Coordination. Do I need to care about that, i.e. does it have something to do with doctor review?
In this case I’m talking about incoming documents, not lab results. So the likely changes would be to the documents table, and in addition a corresponding report is needed (sort of like the Electronic Reports page but for documents instead of lab results).
Your cleint’s requirement is not much different than processing of an inbound ‘Direct’ message. So it may be cleaner to use messages type of list view for all documents. That will permit viewing electronic version of ‘Inbox’ containing documents for multiple patients.
Not sure I follow. If by “Direct” you mean HL7 MDM messages, that is in fact where the documents in question are coming from. What’s this about list view?
‘Direct’/secure message was added by emrdirect. When a secure message arrives, it creates a message for user specified in globals. That user routes message content / attachments to correct patient as an document. If it is CCR, then CCR processing step brings in foreign content into medical record of the patient.
Since ‘Direct’ messaging is MU3 requirement, emrdirect’s workflow will become main interface for practices dealing with other medical systems. Hope here is to have a unified ‘Inbox’ that is supervised but flexible enough to process CCR, scanned documents, HL7s, radiology scans and whatever new stuff that comes to the office. Each of that ‘document’ has same requirement as your client for orderly review that gets logged, commented upon and notified to concerned parties.
Your procedure order, report structures are really part of the ‘documents’ class - just with a lot of structured data. By forcing other documents in that user interface we would loose an opportunity to move towards the generalized inbox that should eventually replace fax/scan and inbound orders interfaces.
OK thanks. I’m looking for a free and open source solution here whereas EMR Direct is a commercial venture.
That said, a “unified inbox” makes a lot of sense, and the fax/scan UI was a step in that direction - but as you say, is not flexible enough for more general application. Does OpenEMR already have EMR Direct code that can be leveraged for this without requiring a subscription?
I think this post and its parent thread is a good backgrounder. EMR Direct is a commercial venture but their contribution in the current codebase is generic enough to work with any mail server.
If there is anything specific to the vendor, it would be in phimail_connect or phimail_check function of /library/direct_message_check.inc. But other functions such as phimail_store and phimail_logit should be good integration point.
They have already provided the ‘background service’ framework and a report that shows the log (Reports->Services). We use this SFTP utility as background service to fetch external HL7 files(Unfortunately there is no user interface to add new background services record in db table).
So many building blocks of an inbox are already in codebase.
