Cleaned up documentation

proj_docs/C0C_1_1_0_T7.TXT

@@ -1,15 +0,0 @@
-=============================================================================
-Designation: C0C_1_1_0_T7.KID
-Package    : CCR
-Version    : 0.7
-Status     : Released
-Date       : Jan 09, 2012
-=============================================================================
-
-Purpose:-
-
-	Date range for all the modules and include notes or not? these values are coming from C0C PARAMETER file as a input values.
-
-Details:-
-	All C0C*.m routines are included.
-	C0C PARAMETER file is also included.

proj_docs/README.txt

@@ -1,4 +1,4 @@
-CCR Package version 1.0
+CCR Package version 1.2
 
 The purpose of the CCR package is to provide support for exporting and eventually importing patient information from/to VistA in XML documents conforming to the Continuity of Care Record (CCR - ASTM) and Continuity of Care Document (CCD - HL7) standards.
 
@@ -112,8 +112,3 @@ Most of the command line interface functions in the package are intended to also
 The "RIM" variables and attributes that are now being stored in ^TMP("C0CRIM") are intended to be maintained in a standard FILEMAN global, and to take advantage of FILEMAN indexing for efficient batch analysis and processing.
 
 It is intended that menu interfaces be provided in addition to command line interfaces for all package functions.
-
-
-
-
-

proj_docs/proj_plan

@@ -1,93 +0,0 @@
-
- Everybody,
-
- We have been spending a lot of time discussing strategies on how we
- are going to proceed about this project. Initially, we were going to
- produce a CCD, and we didn't have quite a plan on how we are going to
- extract the data except as piecemeal. With the advent of the U of Minn
- on the project, and with Emory's discussions, we are going to extract
- a CCR (and I am infinitely happy; the CCD spec belongs to the garbage
- can; I willingly send my abominations to the HL7 committee), and we
- are going to use Mumps Routines called by CPRS for most of the data
- extraction.
-
- There has been a lot of bantering around, and I wish for us to settle
- this by deciding a general strategy and the steps needed to produce
- it, as well as a timeline and expected deliverables. May I propose
- that the initial CCR be generated completely from Mumps without us
- having to do any GUI programming. Why? At this point we have not even
- defined the requirements that any of the steps are going to satisfy
- (at least that is the way it seems to me); developing the stuff in
- Mumps will at least help us define the requirements; plus, it is
- always my belief in anything Vista that the functionality must be
- available using the roll-and-scroll interface. Does that mean we don't
- need Java programmers? Absolutely not! I would like them to work in
- tandem with the Mumps development process to produce the GUI.
-
- Here is my plan, sketched on the plane...
- 0. Read the CCR Spec from beginning to end
- 1. Enumerate the sections of the CCR, defining what data is needed for
- each section. (This step is almost done for us by the spec.)
- 2. Define the needs of the end user on how they are to use the CCR
- functionality (this is very important and has not been done)
- 3. Define a Mumps strategy on how to extract the data (more on that below)
- 5. Define where the data is going to be extracted from (this is being
- carried out by George right now)
- 6. Document Data Output from M/CPRS (RPC's etc.)
- 7. Match data from CPRS with CCR sections
- 8. Define routines that need to be written/modified in order to allow
- us to fill in the missing info for CCR that's not in CPRS (e.g. LOINC
- codes for Labs; they are not in the RPC)
- 9. Write the M code to extract the data from each of the sections
- 10. Write a Mumps XML Writer
- 11. Write the CCR writer that utilizes the XML Writer for output
- 12. Write the CCR user interface that does the user interaction,
- initially in MUMPS, then in a GUI.
- 13. Write a CCR viewer, initially in Mumps, then in a GUI.
-
- I am most concerned with step #2. We need to do mock-ups and present
- them for ideas.
-
- Deliverables (#'s refer to above):
- 1. Spreadsheet
- 2. Needs document; roll-and-scroll and GUI mock-ups.
- 3. Document
- 5. Document
- 6. Series of Documents for each RPC
- 7. Spreadsheet from #1, modified
- 8. Document; work assignments for completion
- 9. Working Code - unit tested
- 10. Working Code
- 11. Working Code
- 12. Working Code
- 13. Working Code
-
- Each of the steps may take a loooooooooong time... Witness George's
- analysis of the RPCs. We need to take advantage as much as possible of
- parallelism; while George is analyzing the RPCs, somebody can be
- writing the Mumps XML output routine, and others can be defining user
- needs, and others can be constructing CCR/Vista data spreadsheets.
-
- The other thing I thought about is how are we going to write the Mumps
- Routines to extract the data. This is all tenative:
- 0. CCRCOMP () - Routine to ask user about patient, purpose of CCR,
- receipient, transmission method, sections, date range
- 1. CCRPROC (DFN, ARRAY1, DUZ, DOCTYPE, BEGDATE, ENDDATE) - Routine to
- process CCRCOMP choices that calls the next routine
- 2. CCRSECTIONS - Outputs data into
- ^TMP($J,"CCR",Section,Name,Value,SubValues,ActorID)
- a. Demograhics (DFN)
- b. Purpose
- c. Payers (DFN, DT)
- d. Meds (DFN, DT1, DT2, DetailFlag)
- e. Labs (DFN, DT1, DT2, DetailFlag) etc etc.
- 3. MXMLWRIT (Name, ATTRIBUTE array, Value) - Writes XML from Mumps
- 4. CCRWRITE (^TMP array) - Write data from ^TMP to the file system
- using MXMLWRIT
-
- --
- Sam
-
- PS: George has been kind enough to host me at his NY apartment for
- hammering out the details of our implementation and show me his
- progress thus far.