Re: [Gnu-arch-users] EMR EBM EBMgmt

[Mitch Amiano]

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.
>
> -t
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
>
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/