[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] EMR EBM EBMgmt
Re: [Gnu-arch-users] EMR EBM EBMgmt
Tue, 14 Aug 2007 08:26:27 -0400
Thunderbird 22.214.171.124 (Windows/20070728)
Thomas, Patrick, forgive me for butting in but when you toss in an
acronym that has almost become a cliché like CMS, I felt the need to
comment on that and a bit more.
There exists a general market (and a size-able one at that) for content
management systems which do not deal with code "source as lines of text"
as it were, but rather as networks of elements inserted as XML. The XML
provides tree structures through various interfaces, mostly but not only
document editing interfaces. A quick look at
http://xml.coverpages.org/healthcare.html shows a plethora of activity
in this area.
The value to the user, if I can read into Thomas' response, is the
ability to use the system to query and retrieve on the basis of the
structures, not just to store and seal it.
DITA, a layered XML standard, provides topical organization and an
ability to impose a class-hierarchy semantic on the tag labels. DITA
exist for asserting domain-specific data types on structured elements.
The existing DITA open source toolkit is generally aimed at technical
documentation, so it provides a code base to leverage for generating
printed and Web based outputs. However, I think that a lot of the XML
compliance focus is on HL7. Therefore, my strategy would be to first
evaluate if a part of HL7 could be used effectively, and if there are
open source components to leverage for it. Then possibly bridge it to
DITA to get a publishing front end, and look at the storage/retrieval
interfaces and querying system.
Doesn't a HIPAA compliant system also have to restrict access on the
basis of roles and privileges? So you'll need some sort of access
control lists or other security controls to even get in the door.
One last comment - where's the money for it going to come from?
Thomas Lord wrote:
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.
Gnu-arch-users mailing list
GNU arch home page: