Fwd: [Hardhats] Re: Playing nicely in VistA: what are the rules?

Some insight from Hardhats that you may all like ... - Wes ---------- Forwarded message ---------- From: Steven McPhelan Date: Tue, Feb 18, 2014 at 2:24 PM Subject: Re: [Hardhats] Re: Playing nicely in VistA: what are the rules? To: hardhats First of all these are now called Integration Control Registry or ICRs. As stated, the VA does not give ICRs outside of VistA as used in the VA. Certain vendors who have national VA contracts can get ICRs if appropriate. ICRs used to be called IAs (Integration Agreements). It is the very principle of ICRs that has made VistA eminently successful in doing distributed development throughout the U.S. with a fairly minimal amount of management oversight. To your specific questions: What do ICRs cover? They cover everything that is within VistA. Every element whether it is a global, a routine, a FileMan data element like an OPTION or RPC, or even non-FileMan globals is assigned to an application (that is namespace) as the owner of that element. 1. An application (that is a namespace) must have an ICR agreement to reference anything outside of its own namespace and numberspace. There are three types of ICRs: a. Private - one between one application and another and no one else can use that ICR b Controlled Subscription - an application can subscribe to an ICR only if the owning application approves. c. Public - the owning application has stated that any other application can use that ICR without having to get prior approval (like with Controlled Subscription). The using application MUST document their use of that ICR in their documentation. The owner of the ICR agrees to make no substantive changes that will affect the ICR without first giving 18 months notification to all of VistA that the behavior of the ICR will change. In other words, the owner ensures backward compatibility. The ICR does not prohibit the owner from adding to the ICR without notification as long as those enhancements preserve backward compatibility. As you can see, with an 18-month notification window BEFORE you can change something, owners may be loathed to put out a public ICR. Obviously the VA have procedures for those cases where a public ICR must be modified without first giving 18-months notice. 2. The VA's ICR is very precise. a. For example, an API that is called by DO with parameters is different from a RPC. A RPC is an entry in file 8994. That entry will invoke a TAG^ROUTINE via a DO with parameters. But the RPC ICR does not grant access to that TAG^ROUTINE. The ICR permits the subscriber to add that RPC entry to a subscriber Broker type OPTION. b. The FileMan DBS APIs are public ICRs. Any VistA package can call them just by documenting that they are using those ICRs. HOWEVER. The FileMan ICRs do not grant a subscriber to use the DBS APIs on any file in VistA. The Subscriber can only use the ICR on its own FileMan files. If the subscriber wishes to use the FileMan DBS APIs on a file that is not within the subscribers domain then the subscriber must have an separate ICR with the owner of the file which will specify exactly what the subscriber can do with the FileMan APIs. 3. How does one outside of the VA file data to a VA VistA file? As we are not going to get ICRs with the VA, then it would be prudent for us to use the safest means possible to make any reference to anything in VistA. The cowboy approach is the worst possible course to take unless one is going to take a version of FOIA VistA and then has no plans to ever try to incorporate future VA patches. You have made VistA your own. However, if you wish to continue to be able to apply VA patches, then the changes you make to VistA should adhere to a term that Cameron came up with around 2001. That is, you will "DO NO HARM TO VISTA". This has a very specific definition. No matter what or how you do something, when you are through you have made changes to VistA EXACTLY the same way the owning VA VistA application(s) would have made those same changes so that that owning VA application would see no differences in what you did versus what the data looks like when entered through the appropriate VistA Option. So, assuming you wish to stay in in sync with the VA patches stream, the best approach to use when updating VistA is to find some Public ICR that supports what you are trying to do. If you cannot find a PUBLIC ICR, then look for a CONTROLLED SUBSCRIPTION ICR. You may find that you have to string 2 or 3 ICRs together to accomplish what you desire. Or you may have a single ICR that returns 10 times the amount of data you need. By using those PUBLIC ICRs in your use, you have a fair degree of assurance that your code will be forwardly (or mostly so) with the VA patch stream. Word of warning, just pulling out an RPC and using it out of context may cause you to DO HARM TO VISTA. This gets back to that other email thread about the BUSINESS RULES in VistA. For example, there are very few CPRS RPCs that work independently. No, the CPRS GUI (i.e., Delphi Code) combines multiple RPCs together to come to a particular conclusion. That conclusion is a business rule that you will not see in the documentation on any specific RPC. This method is not unique to RPCs. The old terminal mode options did the same thing. They called multiple APIs (as we would call it today) and then come to a conclusion. So, to DO NO HARM to VistA, one really should trace all the code from the beginning to the end and observe all the decision points that the original program performed. Then you need to determine whether or not you will observe all of those rules. Some rules may be VA specific and not relevant outside of the VA. SOME RULES are there because the VA must adhere to the LAW OF THE LAND. Congress passes laws specific to the VA which VistA must figure out how to codify. Those LAWS may or may not be relevant to use of VistA outside of the VA. Admittedly, having worked in the VA for so long and being in management, it is not difficult sometimes to see why a programmer MAY HAVE done what they did because of some Congressional Law. Sorry about being so verbose here. But Kevin, if you had these questions at this time with your experience with VistA, then what about those who have much less. Perhaps, you can now understand some of my responses in the past. I believe the VistA product is something many can use. I also believe one should try to stay in sync with the VA patch stream. Rick and I and others have discussed this. Truth is that until very recently, no one had really tried to do this, that is, modify VistA for use outside of the VA and still stay in sync with the entire VA patch stream. So there is not a wealth of experiential knowledge on how best to do this. SAIC took DHCP and forked. SAIC/DoD and the VA were never able to bring their two source code streams back together. IHS did the same thing and today they still cannot bring their respective source code streams back together. History has shown that if you severely fork your source code stream then it will take a very large amount of resources to try to keep your source code stream in sync with the VA's. No one has done to date successfully. I said severely forked. The more you fork your source code the more effort it takes to keep it in sync with the VA patch stream. There is an undefined line which you can cross where it is no longer feasible to keep in sync. Enough preaching. On Sun, Feb 16, 2014 at 10:43 AM, Sam Habiel wrote: > Kevin, > > --Filing data into the file of another package (e.g. TIU NOTES, 8925) > --> Use APIs provided by TIU package. > --Using an established RPC from another package (e.g. reusing an RPC > found in CPRS?) --> Need an IA. > > As far as I know, there is no way today for people outside of the VA > to get an IA. Hopefully that's something we can change soon. > > Here's a list of IA's as of soonish... > > > https://downloads.va.gov/files/FOIA/Software/Integration_Agreements/ALL%20ACTIVE%20IA%20DESCRIPTIONS%20APRIL%202013.txt > > Sam > > On Fri, Feb 14, 2014 at 5:41 AM, Ben Irwin wrote: > > Kevin, > > > > While you can't get to the FORUM agreements, you can search routines to > see > > how they are used. > > > > Using the Google search on www.wbvista.info and selecting routines or > > pasting the following into a Google search box will return many routines > > that are using DBIA. > > > > DBIA site:http://wbvista.info/VDOCS/Routines > > > > Integration Agreements are agreements between packages that say that you > can > > use my data, api, etc. and I promise to keep that data, api, etc > available > > for the life of the agreement. > > > > The Integration Agreements have in the past been controlled by the DBA. > The > > last time I needed a Integration Agreement, Cameron was who I asked. > That > > should provide a clue of how old this information is. > > > > -- > > -- > > http://groups.google.com/group/Hardhats > > To unsubscribe, send email to Hardhats+unsubscribe@googlegroups.com > > > > --- > > You received this message because you are subscribed to the Google Groups > > "Hardhats" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to hardhats+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > -- > -- > http://groups.google.com/group/Hardhats > To unsubscribe, send email to Hardhats+unsubscribe@googlegroups.com > > --- > You received this message because you are subscribed to the Google Groups > "Hardhats" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to hardhats+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- Steve The urge to save humanity is almost always a false front for the urge to rule - HL Mencken -- -- http://groups.google.com/group/Hardhats To unsubscribe, send email to Hardhats+unsubscribe@googlegroups.com --- You received this message because you are subscribed to the Google Groups "Hardhats" group. To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Wesley D. Turner, Ph.D. Kitware, Inc. Technical Leader 28 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4920
like0