When your package needs to prompt a user to look up a patient, use only the approved APIs and RPCs to do so.  Those tools handle all the necessary sensitivity, audit logs, etc, with regard to patients.  As for access to options, etc, the very purpose of the user logon through the appropriate ZU routine (a routine is renamed by ^ZTMGRSET to ZU from the appropriate copy for each M environment that is used in VA) insures that all users only get access to options/files/records that they have been authorized to use.  Those settings are established through Kernel options for delegating menu and option access, file access, location restrictions, etc.  That frees you from having to ever remember what you have to do in your package’s code.

 

The policies that guide development covering the issues you ask about include the Integration Agreements (192-039 Interface Control Registration and Approval.doc at ftp.va.gov/VistA/VistAdocs/Policies/).  Explicitly, only Active, Supported IAs are to be used by any package when software components are used that are external to the package’s name and number space.  So if you do need to access other components outside of your package, e.g. if you need to invoke parts of lab, use the components that are documented in the Integration Agreement list (a text copy is posted at ftp.va.gov/VistA/Software/Integration Agreements).  For example, the management of lab notifications is handled through lab package options and not through your package’s code.

 

It is in this manner that the applications and services in VistA are cohesive within themselves yet loosely coupled between them.  Except for the more dramatic re-tooling that sometimes must (or at least should) be done, changes to the code in one application or service seldom affect other applications and services.

 

Cameron

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Usha
Sent:
Tuesday, March 28, 2006 2:05 AM
To: hardhats-members@lists.sourceforge.net
Subject: [Hardhats-members] Guidelines to write a new routine

 

While creating a new routine, what are the kind of background issues one should keep in mind? Typically, when a routine(corresponding to a VistA option) is run, certain background tasks are to be performed:

 

Checking if the user (DUZ) is allowed to access options/files/records

If accessing a sensitive patient... maintaining the audit log

If a test is completed, to send approprite notifications

restricting sign-on to a specific location etc.

 

Is there any guideline(other than SAC) based on which routines should be written keeping in mind the above & the adhereance to the basic VistA architecture so as to not conflict with future VA enhancements/KIDS patches?

 

Regards

Usha

Reply via email to