source: ccr/trunk/proj_docs/proj_plan@ 1279

 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.