On Sat, Sep 15, 2018 at 06:08:46PM -0300, Pablo Pazos wrote: > Lately I've been working a lot with lab test reports. Current CKM modeling > for this relies on a generic model that applies to any kind and structure > of result in this way: > > - COMPO.report-result // any result document > - OBSERVATION.laboratory_test_result // results container, can be used > as a panel > - CLUSTER.laboratory_test_analyte // single result > > > This kind of generic model relies on specific structures to be set at > runtime, and also to use specific codes to know which type of result is > contained in the analytes (which remembers me of the way CDAs are modeled). > > *An example* > > For a lipids panel result, which contains analytes for cholesterol, > triglyceride, HDL and LDL, we need systems to create that structure and use > specific codes like: > > - COMPO > - OBSERVATION > - CLUSTER = cholesterol, LOINC::14647-2 > - CLUSTER = triglyceride, LOINC::14927-8 > - CLUSTER = HDL, LOINC::2085-9 > - CLUSTER = LDL, LOINC::39469-2
This sort of thing simply feels wrong from a clinical point of view. Each of the test results deserves to stand on its own because (as you show) it will need to be queried on its own. It is only a matter of local convenience, and an arbitrary decision, to group *display* of those under a panel. IOW, the panel certainly is not a PRIMITIVE data type in the domain concept model. Panels are like folders. Whether to define inhabitants thereof by LOINC, by arbitrary instance links, or by other means, is an implementation detail. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B _______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
