Health IT and Electronic Health Activate your FREE membership today |  Log-in
5 pts.
 Network naming conventions?
I know a main consideration when building out your infrastructure for EHR is re-evaluating the enterprise naming convention used. What's the best way to go about this as you position to expand your network?
ASKED: June 11, 2010  9:39 PM
UPDATED: July 4, 2010  12:06 am

Answer Wiki:
The concept of naming conventions is paramount to the creation of "enterprise" networking solutions and will effect your entire infrastructure concerning maintenance, anomaly resoluition, performance, security, training, regulatory compliance and scalability. I think that covers more than most expect hear. Remember this is just a short answer. Let's talk about UNIX based environments in support of medium to large scale healthcare enterprise networking solution (Infranet). I anticipate more questions to follow, so lets begin this from the beginning. UNIX operating systems are designed fortunately and unfortuntely to be highly configurable. The understanding of how to engineer user "accounts", "groups" and "permissions" will make or break your engineering solution, sometimes sooner or sometimes later. If you are lucky, it will be sooner than later. Sooner is good because it will break before you go live and be more embarrassing than expensive. Later, if you only use vendor defaults, because it will always mostly work, but will be much like that of your college campus, not regulatory compliant, hard to map enterprise monitoring solutions, impossible to add OLAP solutions, hard to train operations personnel, forget about security, and oh? you forgot to design an efficient software development life cycle. Conclusion, not designing a good naming convention will hide all your inefficiencies and people will leave because no one will be able to fix it (most who will leave will leave on purpose). Designing a proper naming convention will remove the drama, almost make it boring, and all the promises of using advanced computer technologies will be easier and less expensive to maintain, engineer and plan for. (100,000 foot answer - jzr).
Last Wiki Answer Submitted:  June 12, 2010  9:50 pm  by  jzr   280 pts.
All Answer Wiki Contributors:  jzr   280 pts.
To see all answers submitted to the Answer Wiki: View Answer History.

Discuss This Question:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


One method for naming convention would be to use a 4 character alpha numeric strategy. The development life cycle for migrating updates, fixes to published and unpublished anomalies will be with you for the life time of your EMR. So, you will have production and non-production environments.

Production environments include all servers that process current user sessions with live patient data, meta data servers that stage changes from development servers before going into production, and training environments. Training environments that do not have real patient data will take on the same level of effort and priority that live patient environments have – more on training in another answer.

In a nutshell you will have PRD1 (production), COP1 (copy of production), STG1 (production – meta data server), and MTR1 (production – master training environment). These conventions will translate into UNIX administrative accounts and groups. For example PRD1 will be managed by the UNIX account prd1adm (administrator) and part of groups prd1grp and prd1user. COP1 will be managed by UNIX accounts cop1adm and groups cop1grp and cop1user. You get the drift here?

Following this construction you will have put into place UNIX best practices for managing “ENTERPRISE NETWORKS”. All levels of security that would apply to classified environments but not impede authorized user access, will also be set in place, so long as you continue to apply industry best practices in your implementation strategies – and yes you have to either know or find out what those are.

This particular type of convention will allow you to architect multiple environments within an “enterprise network” implementation that are mutually exclusive, therefore controlling access management, maintenance, monitoring, anomaly resolution and disaster recovery processes that are standardized – since every environment works the same way, just has a different name and business purpose and risk. Under the hood they are the same construction. So this means your technical support staff only has to learn how to maintain one engine since all engines are the same.

On your high priority environments (i.e. production) you would have senior technical staff mentoring junior technical staff. Prioritizing production environments based on business risk – 1)PRD1, 2)MTR1, 3)COP1, 4)STG1. This of course is an example and would be based on your particular business model.

As you can see from the above example, identifying production environments using naming conventions is all to important regarding communications of what will quickly become a complex web of technical issues if conventions are not used.

This answer is focuses on production environments for now. The reason for using alphanumeric is to distinguish “legacy” or “current” from “updated” or “upgraded” development life cycles. New production (version 2 from version 1), will be PRD2, MRT2, COP2, STG2. As you can already begin to see non-production environments will take on similar naming conventions – DEV1, ENG1, QAT1, dev1adm, eng1adm, qat1adm.

Since the only difference are the four character environment names the cognitive algorithms will be able calculate and validate environments on their own. This means the same programs that are used for installation, data migration, refreshing, monitoring, and maintenance are few and not many. This reduces training for technical staff and lends to faster elapse times for anomaly resolution and determining OLAP tracking.


 280 pts.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: