|From:||David Whitten <whitten@xxxxxxxxxx>|
|Date:||Wed, 18 Jun 2014 14:19:26 -0400|
Comments interleaved below
On Wed, Jun 18, 2014 at 12:20 PM, Rich Cooper <rich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
I agree that there are two methods, but I would argue they are two
processes that superficially look the same. (Isn't the ambiguity in
English fun for software development ?)
In the outpatient case, the process is wholly within the Pharmacy,
and the ordering process is by Clinicians. I think part of this is
because the process of dispensing and filling are done inside the
pharmacy, and because patients administer their own meds,
In the Inpatient case, there are different people, (nurses, patients,
pharmacy clerks and techs) who do different parts of this, and
it has to be done over an extended time period. The simple act
of addition on the outpatient process becomes individual steps that
each must be managed, recorded, and performed.
Well, as to orders, I was actually discussing currently working software in a hospital, with its own data structures. So the issue needs to be more than just saying there is another solution, but how to merge the existing solution with the more general solution as you have described above. Especially if you have already deployed software, how do you justify an organizations investment into back-fitting this extra code and data?
In the context of ontolog-forum, I think the rubber meets the road when you start to deal with how to describe what is happening as the process is supported by software, perhaps with a logical model that takes into account time and how the description is being elaborated, and some how make the description integral to the software so it will be maintained as the software is changed. Interoperability between two logical views is not easy.
VistA has explicit data definitions that are used as data is stored, but there still needs to be a way to tie a logical description to the data as it is being created and maintained. We have transaction processing that is part of database handling, how do we maintain the low level software issues to the logical level ?
Actually, that signal does occur. It is called the Administration of the drug, and usually has checks and balances based on bar code scanning, expected time of delivery. There are also issues about failure to scan, and reasons why PRN (as needed) medication was administered, if there was pain, pain-level, pain-location, and so forth.
True enough. Or even if they are willing to execute someone's plan, they may retire without documenting the system, refactor code and data, or otherwise obscure what the original plan was.
The trick is making sure the other needs are visible so the programmer doesn't simplify out needed information or not even record it. Even the things I did yesterday to optimize a process might cause headaches to me today as I try to give a report to someone monitoring or auditing the process.
I think as the impact of any computer program grows, it only monotonically increases its political sensitivity within an organization over time.
_________________________________________________________________ Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/ Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/ Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx Shared Files: http://ontolog.cim3.net/file/ Community Wiki: http://ontolog.cim3.net/wiki/ To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (01)
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [ontolog-forum] Requesting Opinions on the Benefits of Predicates as Nodes, Rich Cooper|
|Next by Date:||Re: [ontolog-forum] Requesting Opinions on the Benefits of Predicates as Nodes, Rich Cooper|
|Previous by Thread:||Re: [ontolog-forum] Requesting Opinions on the Benefits of Predicates as Nodes, Rich Cooper|
|Next by Thread:||Re: [ontolog-forum] Requesting Opinions on the Benefits of Predicates as Nodes, Rich Cooper|
|Indexes:||[Date] [Thread] [Top] [All Lists]|