Eliminate Print Servers: go LANless?
-
@Dashrender said:
A constant complaint I'm hearing is that the docs don't want to be typing in documentation while talking to the patients, it seems rude and impersonal.
What is your proposal to solving that?
Replace the doctors?
That's a normal part of a doctor visit anywhere around here.
-
@Jason said:
@Dashrender said:
A constant complaint I'm hearing is that the docs don't want to be typing in documentation while talking to the patients, it seems rude and impersonal.
What is your proposal to solving that?
Replace the doctors?
That's a normal part of a doctor visit anywhere
around here.FTFY
Definitely had doctors tracking all the info while dealing with out issues a week ago. Very careful record keeping "as it happened." That's as good bedside manner, personal service and patient care / non-rude as it gets. Now if the doctor was carefully recording the situation (video and audio recording in the patient care room for later transcription) maybe that would be okay, but how many patients want to be videod during a normal visit and there is a certain certainty in recording events as they happen because the recording itself can trigger the caregiver to think of details that they forget to clarify.
-
@johnhooks said:
@scottalanmiller said:
@Dashrender said:
@johnhooks said:
@Dashrender said:
I can say legacy or not...
There are three EHRs in play here.
Athenanet - ours
Epic - three of the major hospitals around here use it
Cerner - used by the other hospital systemYa that makes it tough, you probably can't get database access to pull info from the two others.
I can't get DB access to any, athenaNet is a cloud service.
You should never have DB access. The question is if you get API access.
Read only access via ODBC would be helpful so you could query. If it takes them this long to find info making their own reports from a query would help.
no good system would allow that. API means that they control the queries. ODBC means you could be using inefficient queries and that you know database details that an end user should never know. ODBC is "under the hood" and while it works, it's an archaic way to handle this.
-
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@Dashrender said:
@johnhooks said:
@Dashrender said:
I can say legacy or not...
There are three EHRs in play here.
Athenanet - ours
Epic - three of the major hospitals around here use it
Cerner - used by the other hospital systemYa that makes it tough, you probably can't get database access to pull info from the two others.
I can't get DB access to any, athenaNet is a cloud service.
You should never have DB access. The question is if you get API access.
Read only access via ODBC would be helpful so you could query. If it takes them this long to find info making their own reports from a query would help.
no good system would allow that. API means that they control the queries. ODBC means you could be using inefficient queries and that you know database details that an end user should never know. ODBC is "under the hood" and while it works, it's an archaic way to handle this.
Yes but if you're not a developer, who has the ability to spend possibly weeks learning their API and building an application to do this?
I can't believe that's archaic at all. It is still used all the time by tons of people.
End users aren't seeing any database details. You write the query and set the report up, they just type in a name and date or whatever info is required.
-
@johnhooks said:
Yes but if you're not a developer, who has the ability to spend possibly weeks learning their API and building an application to do this?
.Should be the opposite. API should take less effort than having to code "under the hood" and learn their database and relationships and figure out what correct data is and isn't. ODBC means you have to do ALL the work rather than accepting the resulting data. For the reason you mention, ODBC has been replaced for two decades as how to handle these situations.
-
@johnhooks said:
I can't believe that's archaic at all. It is still used all the time by tons of people.
So Windows 98 isn't archaic? You are actually saying that you don't believe that client/server programming isn't archaic? We were laughing any anyone doing this by the late 1990s. It's as archaic as it gets in IT. Unless maybe you are running this on your PDP-11.
-
@johnhooks said:
End users aren't seeing any database details. You write the query and set the report up, they just type in a name and date or whatever info is required.
YOU are the end user here. This is not your database or your application.
-
@scottalanmiller said:
@johnhooks said:
I can't believe that's archaic at all. It is still used all the time by tons of people.
So Windows 98 isn't archaic? You are actually saying that you don't believe that client/server programming isn't archaic? We were laughing any anyone doing this by the late 1990s. It's as archaic as it gets in IT. Unless maybe you are running this on your PDP-11.
Who was laughing at people doing this? You were laughing at people using a technology in the 90's that was newly developed in the 90's?
How is this https://developer.spotify.com/web-api/endpoint-reference/ any easier to learn than a database structure? And that's only for Artists, tracks, playlists, and profiles.
API should take less effort than having to code "under the hood" and learn their database and relationships and figure out what correct data is and isn't
There is no programming here. It's SQL query generation and then repeated with a report that spits out a PDF or whatever you want.
-
@johnhooks this is more of Scott's fantasy island thing. I only argue with him on these silly statements when I am bored.
-
The core of what is printed is information from the other systems that we have no APIs into. All we have is the ability to print the information, either to paper or PDF.
That information can be saved into the current EHR. The problem with this information is that it's non searchable at all, it's just an image. My EHR does not have any OCR ability with regards to these PDFs - they are just dumb pictures basically.
-
@johnhooks said:
Who was laughing at people doing this? You were laughing at people using a technology in the 90's that was newly developed in the 90's?
Client / Server architecture goes back to the 1970s. It was already very old in the 1990s and widely known to be a major problem with security, safety, scalability, etc. Developers were laughing at people trying to implement things from decades past in new code.
-
@johnhooks said:
How is this https://developer.spotify.com/web-api/endpoint-reference/ any easier to learn than a database structure? And that's only for Artists, tracks, playlists, and profiles.
That's failed logic. That you feel that "someone" has made a complicated API has no bearing or relevance to the fact that an API is the right way or easier potential way to work. The database behind that API could be any degree of complex that you do not anticipate as well. You are using the assumption of an easy database structure with a real world API. Even this isn't an example of an API that is harder, only an API you feel is hard. So it doesn't suggest that what you propose is true. At best it is an example of a bad API.
-
@johnhooks said:
There is no programming here. It's SQL query generation and then repeated with a report that spits out a PDF or whatever you want.
Who is generating the query? How do you get a query without someone writing it? I can pull data from an API without code, too, in the same manner.
-
@scottalanmiller said:
Best technique is, of course, to get rid of printing
It's amazing to me how people get so "attached" to printing (almost like it's a measure of self worth)
I mean, people freak out if they can't print! -
@scottalanmiller said:
@johnhooks said:
Who was laughing at people doing this? You were laughing at people using a technology in the 90's that was newly developed in the 90's?
Client / Server architecture goes back to the 1970s. It was already very old in the 1990s and widely known to be a major problem with security, safety, scalability, etc. Developers were laughing at people trying to implement things from decades past in new code.
Developers at what company? ODBC is still used today.
-
@johnhooks said:
Who was laughing at people doing this?
I know, for example, that NTG was confident that we were getting development work from UPitt in the late 1990s because we were proposing using 1990s architectures instead of 1970s and 1980s architectures that they had been using. That was the 1990s and we had been doing that kind of work for years and we were hardly pioneers, we were pretty much development newbies. By the time that we were learning modern architectures in the later 1990s the idea that n-tier had completely displaced client/server and that c/s was a ridiculous idea whose time had come and gone was passé to even discuss. By the late 1990s, that c/s was an idea that should never be implemented on new systems was roughly like deploying physical servers today instead of virtualizing. Sure, lots of people who don't know what they are doing and are totally out of touch still do it, but we all know it is ridiculous for new systems.
-
@scottalanmiller said:
@johnhooks said:
How is this https://developer.spotify.com/web-api/endpoint-reference/ any easier to learn than a database structure? And that's only for Artists, tracks, playlists, and profiles.
That's failed logic. That you feel that "someone" has made a complicated API has no bearing or relevance to the fact that an API is the right way or easier potential way to work. The database behind that API could be any degree of complex that you do not anticipate as well. You are using the assumption of an easy database structure with a real world API. Even this isn't an example of an API that is harder, only an API you feel is hard. So it doesn't suggest that what you propose is true. At best it is an example of a bad API.
And that's an API written to be used by anyone. It's not an API written by an EMR company that doesn't have everyone looking at it. That would almost always be much more complex. Especially with all of the data that's contained there.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
Who was laughing at people doing this? You were laughing at people using a technology in the 90's that was newly developed in the 90's?
Client / Server architecture goes back to the 1970s. It was already very old in the 1990s and widely known to be a major problem with security, safety, scalability, etc. Developers were laughing at people trying to implement things from decades past in new code.
Developers at what company? ODBC is still used today.
Sure, and I have no idea why you are talking about it. ODBC isn't the issue, client/server design is. Don't use ODBC as an end user.
-
@scottalanmiller said:
@johnhooks said:
There is no programming here. It's SQL query generation and then repeated with a report that spits out a PDF or whatever you want.
Who is generating the query? How do you get a query without someone writing it? I can pull data from an API without code, too, in the same manner.
What applications can you use that generate API code for you? I can think of quite a few that will generate SQL for you based off of what you tell it.
-
@johnhooks said:
And that's an API written to be used by anyone. It's not an API written by an EMR company that doesn't have everyone looking at it. That would almost always be much more complex. Especially with all of the data that's contained there.
Why would it be assumed to be more complex? I use APIs every day that are not designed to be used by people (ML's for example, SW's, etc.) and they are dead simple. Your logic doesn't flow. Yes, the EMR company might screw up the API, but it might be super simple too (or not exist if they are total crap software.) But you are taking one bad API example from a company that makes consumer software for music, making assumptions about the simplicity of their database and using that unfounded combination of assumed easy relational database, combining it with assumed complex API and using it to derive the complexity of unrelated databases and APIs on which it has no bearing.
You might as well say that Microsoft Word is complex because Spotify is hard to use. What does one have to do with the other?
