patrick blanchard wrote:
Unless I am missing something, domain-specific data types in medicine
are not any different than CMS. Ok, so they might have a different tag,
but that's all.
The key thing to consider is that CMS systems mostly deal with
files of source code. The syntax of most programming languages is
such that a revision control system for CMS can treat those source
files as a "list of lines" -- a sequence of strings, one string per
line. For example, if someone saves a change to a file, the revision
control system can usefully think about that change in terms of "what
lines were added to this file and which were deleted?". Another
example: a revision control system for CMS usefully includes a feature
like "find me all of the lines of code that contain the string X" or
"tell me all of the changes that have been made to this line of code".
In a PHR, that "line-oriented" view of changes is less obviously
useful. You might want to know the history of changes to the
patient's weight record, for example. Well, don't you want to be able
to ask "How has the 'weight' field on this chart changed, over time"
rather than having to phrase the same question in ad hoc terms like
"How have lines 10-15 of file X changed, over time"?
I don't think the catagory problem is really a problem after all,
unless you want to start storing voxel image in a 3d array. If the data
type is kept 2d, then Perl can sort out the minutia, while Arch can do
the bird's eye view of data changes. It might work w/ a medical
specific markup language similar to HTML. ...just some thoughts. CGI
can make it presentable to the enduser. I'll bet what you have already
will take this 90% of the way, and surpass 100% of the EMRs on the
market.
I can't speak to the real world problem that you are trying to solve,
right now. You know that problem -- I don't. If Arch in its current
state is just what the doctor ordered (sorry :-), go for it. I just
think that the "leap-frog" plays in EMRs/PHRs is -- well, similar to
Arch but also similar to file systems, git, and a few other things;
and that the leap-frog play makes it possible to handle data (like
"weight" vs. "line 10 of file x") with semantic precision.
-t
|