Cleaned up documentation

This commit is contained in:
sam 2012-10-02 18:02:48 +00:00
parent ba3ef28e5d
commit f7688bd7bc
5 changed files with 1091 additions and 114 deletions

View File

@ -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.

1090
proj_docs/INSTALL.txt Normal file

File diff suppressed because it is too large Load Diff

View File

@ -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.

View File

@ -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.