Eliminate Print Servers: go LANless?
-
@johnhooks said:
@scottalanmiller said:
All ODBC is easy and self describing (Known false.)
First off how is this a known false? Username, password, done. That's easy. If you're referring to the data behind the ODBC, then that's different.
I'm referring to the data behind it.
-
@johnhooks said:
Provide a simple API?
Look at the MangoLassi URL. That's a very common HTTP-based, XML returning, RESTful API.
-
Spiceworks uses a similar API. So easy that you can just look at it.
Have you ever worked with Ruby on Rails? It makes the API for you as you go and drives home how it is used. By default, many modern frameworks create super simple APIs as part of their framework itself.
-
-
@scottalanmiller said:
@johnhooks said:
Provide a simple API?
Look at the MangoLassi URL. That's a very common HTTP-based, XML returning, RESTful API.
an EMR and a forum site are not comparable at all.
-
Second you are assuming that the APIs are going to present the information in a readable way which is a known false.
-
@johnhooks said:
an EMR and a forum site are not comparable at all.
But Spotify is what you are basing things on?
But an API is an API. If you use Ruby on Rails (purely an example) to build an EMR, you'd get, by default, the same API standard.
There is a reason why APIs have standardization, to make them as easy as possible to consume. EMR has no reason not to leverage the same API standard.
-
@johnhooks said:
Second you are assuming that the APIs are going to present the information in a readable way which is a known false.
Not really, the API presents it in the "presented form." Whatever that is. No response is guaranteed to provide a good output, but the API responds with a response that is the vendor's representation of the data. If it is not readable, too bad, you don't have data. But it is what the EMR is giving you. If you use ODBC, you are not using the EMR but bypassing it. Totally different thing.
-
Your argument about bad API output is the assumption that the application might not work. Okay, but if the EMR isn't working, isn't all of this moot?
-
All of this is moot anyway, no EMR vendor is going to consider providing access directly to their raw data. Never going to happen. Ever. So completely out of the question there really isn't a point in discussing it outside of a theoretical "wouldn't it be nice?" Getting API access might be unlikely, but it is a distinct possibility and a feature that better vendors would want to provide as a feature.
-
Even simple database information, like record number, are not artefacts that any vendor wants to expose to clients. You don't want a doctor knowing that he has just entered "record #150." Or at least you don't want him thinking that.
-
@scottalanmiller said:
All of this is moot anyway, no EMR vendor is going to consider providing access directly to their raw data. Never going to happen. Ever. So completely out of the question there really isn't a point in discussing it outside of a theoretical "wouldn't it be nice?" Getting API access might be unlikely, but it is a distinct possibility and a feature that better vendors would want to provide as a feature.
Even on site a lot of programs shouldn't give direct access. Wouldn't that be a violation access controls and audit. We have many programs which install the DB and we never get the encrypted SQL passwords for them.
-
As an example, as someone who has led development teams and worked with clients, I've seen clients attempt to do things exactly like you are doing, trying to use raw database data without going through the proper API and getting lots of bad data because they misunderstood the data representation in the database. They weren't even given raw access, but seeing one ID field was enough to confuse them and have them think that they were able to produce data that they were not and they ended up with a lot of data integrity problems because of it.
And if you had been a developer on our side, the database was super obvious and simple (still is.) But as an end user not understanding the design or design considerations or other users of the system and so forth, the data looked like it might say things that it did not. The application did not try to interpret those artefacts, but end users without database documentation were quick to attempt to do so.
-
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
At least the data has to have some kind of structure.
Here is the rub. This is not only not necessarily true, it's not even likely to be true.
If it's a relational database it has to. Like I said, you can't break the first normal form with a relational database.
Sure can, and some relational databases don't even support enforcing it. And there is no reason to even think it is likely to be relational. That's rather unlikely for such a modern app doing what it does. Why is relational even being brought up outside of a "well, I suppose it might be relational."
Explain how it's possible? How can you have a tuple that doesn't have all of the attributes? That's impossible.
Lots of databases and applications happily do not enforce no-null. So many that it is normally assumed. Nulls are very common. No matter how bad of a form it is, it is the most common way to set up a tuple.
I don't know what you're saying here. It's either null or it's not. Null has no data, not null is data.
-
@Jason said:
@scottalanmiller said:
All of this is moot anyway, no EMR vendor is going to consider providing access directly to their raw data. Never going to happen. Ever. So completely out of the question there really isn't a point in discussing it outside of a theoretical "wouldn't it be nice?" Getting API access might be unlikely, but it is a distinct possibility and a feature that better vendors would want to provide as a feature.
Even on site a lot of programs shouldn't give direct access. Wouldn't that be a violation access controls and audit. We have many programs which install the DB and we never get the encrypted SQL passwords for them.
You could make those things secure from an access perspective, but it would be a pain. It would mean maintaining two sets of access controls and needing to protect the data in ways that may not have been planned for or foreseen or, at least, having to go through extra work to secure them properly and think through more scenarios. It's a large attack surface and more complexity to deal with.
The bigger concerns are typically around performance. Letting people write their own queries means you cannot enforce optimization - the tools that you use to make your main application fast and efficient and the full time database people or ORM tools are not in use and there is a possibility of tons of complex, expensive queries hitting the database. Sure you could limit access times but.. more complexity and people management to deal with.
There are really special cases where things like data analysts have full access and a reason to do things so complex that they need the ability to query directly - but typically they are also given their own databases as well and not part of the normal data pool because of it.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
At least the data has to have some kind of structure.
Here is the rub. This is not only not necessarily true, it's not even likely to be true.
If it's a relational database it has to. Like I said, you can't break the first normal form with a relational database.
Sure can, and some relational databases don't even support enforcing it. And there is no reason to even think it is likely to be relational. That's rather unlikely for such a modern app doing what it does. Why is relational even being brought up outside of a "well, I suppose it might be relational."
Explain how it's possible? How can you have a tuple that doesn't have all of the attributes? That's impossible.
Lots of databases and applications happily do not enforce no-null. So many that it is normally assumed. Nulls are very common. No matter how bad of a form it is, it is the most common way to set up a tuple.
I don't know what you're saying here. It's either null or it's not. Null has no data, not null is data.
Outside of having a null for id information, if you have a tuple, how do you guarantee that you know its relationship to other tuples? If all you have is a linked list, fine, but that's not a relational database, it's a list. It might be stored in an relational engine and presented via a RDBMS, but it itself isn't relational. You aren't relational until you have more than one table.
-
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
At least the data has to have some kind of structure.
Here is the rub. This is not only not necessarily true, it's not even likely to be true.
If it's a relational database it has to. Like I said, you can't break the first normal form with a relational database.
Sure can, and some relational databases don't even support enforcing it. And there is no reason to even think it is likely to be relational. That's rather unlikely for such a modern app doing what it does. Why is relational even being brought up outside of a "well, I suppose it might be relational."
Explain how it's possible? How can you have a tuple that doesn't have all of the attributes? That's impossible.
Lots of databases and applications happily do not enforce no-null. So many that it is normally assumed. Nulls are very common. No matter how bad of a form it is, it is the most common way to set up a tuple.
I don't know what you're saying here. It's either null or it's not. Null has no data, not null is data.
Outside of having a null for id information, if you have a tuple, how do you guarantee that you know its relationship to other tuples? If all you have is a linked list, fine, but that's not a relational database, it's a list. It might be stored in an relational engine and presented via a RDBMS, but it itself isn't relational. You aren't relational until you have more than one table.
Primary and foreign keys.
The first normal form doesn't deal with other relations. It only says that tuples in a relation need the same attributes. You can't have a tuple with more or less attributes than other tuples in the same relation.
So in my example, the simplest form would be cust_id, lname, fname, address, city, state, zip, phone, spouse, invoice_number, invoice_date, invoice_amount, etc.
That may be like a giant spreadsheet, but it's still a relational database. If I have a tuple and I don't fill in the spouse attribute, it's null. It's not empty, but null. So that tuple still has an entry for the spouse attribute.
-
@scottalanmiller said:
All of this is moot anyway, no EMR vendor is going to consider providing access directly to their raw data. Never going to happen. Ever. So completely out of the question there really isn't a point in discussing it outside of a theoretical "wouldn't it be nice?" Getting API access might be unlikely, but it is a distinct possibility and a feature that better vendors would want to provide as a feature.
http://qrshs.com/paradigm-pm-optional-modules-odbc-connectivity
https://www.henryschein.com/medical-practice-management-software.aspx
There's a few after a quick search.
-
@johnhooks said:
So in my example, the simplest form would be cust_id, lname, fname, address, city, state, zip, phone, spouse, invoice_number, invoice_date, invoice_amount, etc.
That may be like a giant spreadsheet, but it's still a relational database. If I have a tuple and I don't fill in the spouse attribute, it's null. It's not empty, but null. So that tuple still has an entry for the spouse attribute.
By that logic, all files are relational databases. NoSQL are all relational. A CSV is relational. Just a text file would be.
Null is not valid in traditional relational data. Call it filled or not, it's not considered valid.
-
@johnhooks said:
@scottalanmiller said:
All of this is moot anyway, no EMR vendor is going to consider providing access directly to their raw data. Never going to happen. Ever. So completely out of the question there really isn't a point in discussing it outside of a theoretical "wouldn't it be nice?" Getting API access might be unlikely, but it is a distinct possibility and a feature that better vendors would want to provide as a feature.
http://qrshs.com/paradigm-pm-optional-modules-odbc-connectivity
https://www.henryschein.com/medical-practice-management-software.aspx
There's a few after a quick search.
These provide ODBC access to their hosted database?
