Afsin Ustundag

Preliminary Deliverables List of application layer modules Already in the OSEHRA Architecture document Number of applications: 168 Identification of interfaces required and list of common services Start from XINDEX results More detail by code investigation, automation Similar project ongoing within OSEHRA?

Refactoring Deliverables Refactored Module Software Source Codes Module of our choice Scheduling is suggested No new functionality added Mainly reorganization of existing code to make it more modular and accessible Making the code compliant with OSEHRA guidelines Open source community to be engaged and participate

Delivered – Package Interfaces Automated Package to Package Interfaces Routine to routine only. Package routines are identified from namespaces. Uses XINDEX variant. Interfaces are specified as tags in routines Formal parameters. Inputs and outputs. Globals (top level). Indirection and Xecute statements. Read and Write statements.

Delivered – Package Interfaces Example Interface from Problem List Package GETLIST^GMPLHS CALLING PACKAGES : HEALTH SUMMARY,ORDER ENTRY/RESULTS REPORTING FORMAL: GMPDFN,STATUS INPUT: DUZ*,GMPDFN,GMPLVIEW*,IO,ION,IOST,IOT,ORWINDEV,SCS* STATUS,U OUTPUT: %,C,DI,DIL,DIQ0,DIQ1,DIQ2,DRS*,GMPLIST*,GMPTOTAL,I,J SCS*,X,Y GLBS: ^%ZOSF,^AUPNPROB,^DD,^DI,^DIC,^GMPL,^TMP,^VA READ: 0 WRITE: 1 PKG GLBS: ^%ZOSF,^AUPNPROB,^DIC,^GMPL,^TMP,^VA PKG EXEC: 1 PKG IND: 0

Delivered – Package Choice Choice of a preliminary package We chose Problem List. A package that does not have too many dependencies. A package that does not have too few dependencies. A clinical package. Has a menu based UI and GUI (CPRS).

Future Work - Dependencies Routine interfaces are not the only dependencies VistA file ownership. Global ownership. GUI RPCs. Data as Code (Faux Routines). Needs identification and automation Interfaces Needs to be fully validated. Namespace identification should be automated.

Future Work - Testing Understand OSEHRA resources and procedures. Understand VA resources and procedures. Automated tests? Test plans? Test data? MUnit? Determine and implement testing strategy. Requires understanding the functionality of Problem List package from user point of view. Test data? VA eHealth University?

Future Work - Refactoring Identify and separate presentation layer Can we implement a simple Problem List GUI? Needs more understanding of the code. Most read/writes are in common services? Do we move it to application layer? Needs more understanding of CPRS. Any business logic in CPRS? No Problem List RPC entries in ^XWB(8994? Problem List is manipulated through Order Entry package? Initialization and authentication? Need to look at Medical Domain Web Services (MDWS)

Future Work - Refactoring Identify and separate business logic Part of it is identifying presentation layer. Move direct data access to lower levels (FileMan). Move direct global lookup. Move Xecute statements. Limit indirection. Replace direct update calls to other packages with simple generic listeners? Define API’s between packages if not there.

Future Work - Refactoring Contribute XINDEX based utility Additional functionality already added for deliverables. Needs to be improved for dependencies. Improve as a tool to gather information about the codebase and globals. Looking at it as a automated refactoring tool. New all local variables. Add formal parameters. Replace old style tag/goto based loops. Identify dead code.