On 15/07/2006, at 10:29 PM, Tim Churches wrote:
kuang oon wrote:
layer 4: Simple health electronic exchange protocol (SHEEP)- is the
Level 4 interoperable health exchange data format amongst a
plurality of
systems using disparate coding systems / ehr architectures. It is
longhand natural health language segmented by pragmas. Instead
of the
subject-verb-object syntax of conventional English, it uses
storyline-genre-subject-{key-value predicates}. The design goal
being
that the SHEEP document that a human read is good enough for the
computer. Look ma - no codes!
I see current hospital discharge summaries meant for human
eyes tweaked to be sheepshaped for both man and machine. SHEEP
interoperability is about leveraging on the massive sunk costs of
existing and about to be implemented health systems across the entire
health spectrum.
...
On 14/07/2006, at 7:36 AM, Ian Haywood wrote:
Can you publish a formal spec, Kuang?
Yes, asap on a sheep oriented website....
Kuang,
A technical question: Are SHEEP documents small enough to easily be
stored entirely in Random Access Memory to facilitate fast retrieval?
Tim C
Hi Tim,
Definitely. I just measured the byte size of a number of sheep
documents from my own clinical practice. Typically a reasonably good
clinical summary - including all admin data is around 1300 to 1500
bytes. What I recommend is that you create the following 3 Hashtable/
Dictionary objects with patient id as key and respectively the sheep
document string as value, the doclescript representation of sheep as
value and the fully qualified docles (representing the doclescripts)
as values. Alternately create 1 Hashtable in RAM with the patient id
as key with value being another Hashtable with the keys of 'sheep'
'doclescript' and 'docle'. How many records have you got? On the
same database you would have records with the following fields 1)
sheep 2)the doclescript representation of the sheep and 3)the fully
qualified docles derived from the doclescript. What's the hurry? I
would have thought that there is greater flexibility persisting the
data on sql tables. And I know a good patient id system.
HTH
Kuang
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
