Column Naming Conventions (rears it''s ugly head again :)
-
Michael,
Thanks for your post/info with the "health care providers" stuff. It was very informative for me (and I'm sure the others following this thread). Your excerpts are right on the money, as that pretty much is exactly how our app. works. The visit record is most important thing in our world, as you are right, items like vital signs, medication/procedures ordered, etc can be ordered, updated, expired after 24 hrs (in EM dept.), then re-ordered, etc and all require a NEW unique form/visit record to be completed for that patient. Very complex
We are in Canada, but like many other areas, we in the medical arenas are working towards either developing/contributing towards "world-wide" standards, and/or adhering (as much as possible) to the existing approaches out there. I.e. HL7, HIPAA, AHIMA, etc. And for future and in our specific area, some Canadian standards: CEDIS (Canadian Emergency Department Information Systems), NACRS (The National Ambulatory Care Reporting System) are being examined.
I’ve also been trying to read the ISO stuff when I can… But many of these 'standards' are big documents that no one has time to read (at least on work time) and they don’t really define the data in a usable and useful manner!
The US seems to be moving ahead on a lot of this kind of stuff. Where did you get that info that you posted?! It sounds like a document that I actually would want to read
!Jeff…
Yes, the medical community can be it’s own unique little world when it comes to IT. Problem is usually $, and most health communities are very behind in IT simple b/c they can’t afford it.
As far as data, there are so many issues and so much complexity to the systems that no “vendors” really want to touch it… and selling it would be hard, as again no $ in the medical areas to buy it.
As far as my situation… for the current version upgrade (for clinical front-end reasons), we've chosen to update and normalize the DB as far as we can based on the restrictions of what we can get the users to actually do on the front-end, and what the app. will support without MAJOR front-end re-design. "Enforcing" certain aspects of data integrity has to wait for the next version, as we simply can't get the users to actually put the information in J! Clinical users are typically very poor computer users and slow technology adopters.
Cheers.
Michelle (Dolphin).
"Work like you don't need the money;
dance like no one is watching;
sing like no one is listening;
love like you've never been hurt;
and live every day as if it were your last."
~ an old Irish proverb -
(My 2 cents worth)
Michelle, major changes in technology are very often complex and expensive. In many cases the cost are excessive due to poor design. I am a firm believer in using the STS (socio-technology system) when designing or planning for major changes in technology. (Defining technology as the practical application of knowledge especially in a particular area.) This model (STS) requires that the end user or users be involved in the development process from the beginning. There is seldom one end user and each will have their own requirements, which often conflict with other users requirements. One of the major advantages of a normalized database is that once the data is stored in the system the process of extracting and turning this data into useful information is greatly simplified.
It has often been said that change is the only constant in the universe. I think this should be modified to state: Change and resistance to change are the only two constants in the universe. Resistance to change can be mitigated by involving all individuals who will be affected by the change. This process can be long and involved but uses relatively few resources. You can have it Fast, Cheap, or Good pick any two.
It would appear that you are in the middle of a major technological change where insufficient time has been spent involving all the actors. Patching the database this year knowing that you will have to change it next year after re-designing the front-end increases the cost of the change. However, it does provide job security for the IT people.
An interesting article on STS (socio-technology system) can be found here http://www.ics.uci.edu/~wscacchi/Papers/SE-Encyc/Socio-Technical-Design.pdf#search='SocioTechnical'
Mike
-
In reply to:
Oh.. Ray... I'm not sure what you mean by "If you're using variables outside of SQL Columns use @TableNameColumnName rather than just the column name". Can you clarify a bit more or direct me to an example?
Don't give the columns a tablename prefix, but do give your variables a tablename prefix as in this example...
create procedure usp_GetCustomerName
(@CustomerId int, @CustomerName varchar (60) output)
AS
set nocount on
select @CustomerName = Customer.Name
from Customer
where Customer.Id = @CustomerId
go
Rather than simply naming the variables the same as the short column names, (Id and Name), prefix them with the table name like CustomerId and CustomerName.
Someone mentioned prefixing the key columns with tablename such as CustomerID, Name, Address, Zip... That works well too. If you do that, then don't bother prefixing those variable names though, use the same name as the column, which is already prefixed.
Ray
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply