Well, since I'm using option (1), the issue is no longer of immediate
concern (option (1) involves single documents containing all types of
patient data, not separate documents for each type). It would become
a concern, however, if performance proves to be inadequate and option
(3) is used to address the issue.
In considering option (3), I was originally thinking of the directory
structure you describe, but I thought that organizing things based on
type of data might make it faster to search across all patients for
specific data by using cts:directory-query() to limit the scope of the
search to the directory storing a particular type of data. But I see
your point about using a directory structure that, in a RESTful sense,
models the patient as the primary resource. I suppose then that the
XML structure of the individual documents would be the facility used
to narrow the scope of the search (i.e.
cts:element-query("demographics", <rest of the query>) assuming that
the demographic data documents have root node <demographics>). I
would expect that to be slower, though (slower than using a
directory-query).
When you say that a structure reflecting the view of patients as the
primary resource has many benefits, are you thinking in terms of
ability to expose the data as a RESTful service? What other benefits
are you thinking of?
Thanks,
Karl
On Sat, Dec 19, 2009 at 9:13 AM, Lee, David <[email protected]> wrote:
> I attended workshop at Balisage 2009 where a developer was modeling very
> similar data,
> HL7 based patient information. In his case I dont think he was using
> MarkLogic, but the structure
> of the data and the rationale I think bear consideration.
> His design used directories for patient data but inverted from your structure.
> This design is more "restful" in the sense that the directory structure
> itself models a aggregate model based around the patient, not the part (lab
> test, info etc). And the URI's follow a left-to-right decomposition of
> document from container to contained.
>
> TO jump to the conclusion, I would suggest a structure
> Not like your suggestion
> /demographics/10291004
> /lab-results/10291004
>
> but rather
>
> /patients/10291004/lab-results/...
> /patients/10291004/demographics/...
>
> You can use Collections if you wish to group all 'lab-results' across all
> patents
> but the primary directory structure is related to the patient, which in a
> patient data model is the
> primary (top level) object and having the directory structure directly
> reflect that has many benefits.
>
>
> ----------------------------------------
> David A. Lee
> Senior Principal Software Engineer
> Epocrates, Inc.
> [email protected]
> 812-482-5224
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
