Hi, Speaking from the HL7 RIMBAA perspective, and echoing a lot of older cross-industry best practices: to create a database solely based on the RM is fine - if your aim is to have a database that's not optimized for any particular purpose, one that can be used for any purpose. In HL7 we've seen a lot of implementations of this type of approach when it comes to research, clinical trails, public health databases. One will never know what sort of queries will be important at some point in the future, so the architecture (on purpose) is chosen in such a way that it is generic. In general such an approach is known as OLAP. This approach carries a penalty in terms of performance, but that may not be an issue in research/clinical trials/public health anyway.
If you're going to use the data for a very specific workflow or purpose, or if you know exactly how things are going to be queried for, then obviously the database structure (and indexes) are going to be optimized for that specific workflow. In other words: OLTP. But this has the significant drawback (like many proprietary DBMS schema) that it's less flexible: if the workflows change one has to redo the database schema to maintain performance. For this reason one quite often sees both next to each other: an OLTP database to support the ongoing workflow and a limited number of optimized queries, and an OLAP store for long term archival and to allow ad-hoc complex queries, or to extract new data sets for new OLTP-style databases. > When we have approached openEHR storage we have tried to keep use > cases separate and not solve everything with only one database > structure. > > A simplified (perhaps naive) version of the reasoning: > 1. If you want to access data as big chunks in a certain serialization > format (like openEHR COMPOSITIONs used in daily patient care), then > store them in such chunks (and index on fields relevant to your > retrieval needs). > 2. If you want to access small data fields from huge amounts of EHRs > (like population wide statistics/epidemiology) then store them as such > small pieces. I concur. Differences in granularity and differences in relying on (and: maturity of) composite structures such as archetypes and templates tend to lead (when looking at HL7) to OLAP-style data bases. For HL7 CDA implementations we've seen the approach where CDA-sections are persisted as XML-blobs. CDA-sections are the level of aggregation used within the application, so it didn't make sense to have a database model that's fully atomic with regard to the RM. >> The granularity of the archetypes is mostly determined by issues of >> clinical validity and reuseability, rather then performance. We do try >> to keep archetype tree structures as 'flat' as possible i.e remove Ian wrote: >> So indexing on dates, diagnosis / procedure codes and workflow IDs is >> probably the key. It probably is, if one tries to generalize from workflow-supporting applications in daily use. Although one can probably make general recommendations about indexing on certain aspects, it's difficult to do so if you look at the full variance of such workflows in healthcare. >> You might find it helpful to speak to the HL7 RIMBAA community. >> Although starting from a very different RM, they are essentially >> facing a similar low-level engineering problem. (I will get killed by >> both communities for that statement!!). It is indeed a similar problem, which is why we (as HL7 RIMBAA) are looking with interest to the implementation experiences being discussed on this list, and why we had a joint implementers meeting in Sydney (during the HL7 meeting). TTYL, -Rene -- ------------------------------------------------------------ Rene Spronk Cell: +31 (0)655 363 446 Senior Consultant Fax: +31 (0)318 548 090 Ringholm bv The Netherlands http://www.ringholm.com mailto:Rene.Spronk at ringholm.com twitter:@Ringholm skype:rene_ringholm Ringholm is registered at the Amsterdam KvK reg.# 30155695 ------------------------------------------------------------ Ringholm bv - Making Standards Work - Courses and consulting
