94 lines
4.2 KiB
Plaintext
94 lines
4.2 KiB
Plaintext
|
|
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.
|