[Forwarded response from Sam Heard] Thomas Beale wrote:
> > In the current issue (3.11) of the EHR reference model, we have > documented the concept "contribution" as being that collection of > TRANSACTIONs corresponding to a single clinical session. That is to > say, due to a patient contact, there could be the following new > TRANSACTIONs: > > - patient contact (this causes a new VERSIONED_TRANSACTION) > - update to family history transaction (new version in existing > VERSIONED_TRANSACTION) > - update to current medications (new version in existing > VERSIONED_TRANSACTION) > - update to plan (new version in existing VERSIONED_TRANSACTION) > - etc > > So the contribution in this case would be four TRANSACTIONs, each in > distinct VERSIONED_TRANSACTIONs, and each having identical details in > the CLINICAL_CONTEXT object. > > Now... contributions are the unit of change of the record. The > question is, do we need to be able to easily find them after the fact, > or is it not really important. If it is not important most of the > time, then we can do nothing, sicne they will in fact be findable by > looking for those TRANSACTIONs which have the right CLINICAL_CONTEXT > objects. However, this will be slow, as it means going through all > transactions in the entire record. If it is important to be able find > contributions quickly (as I have theorised in the past, and Andrew > Goodchild at the DSTC suggests), then we need to formalise the concept I do not think that we do but I am happy to hear what people have to say. I think it is the same function as putting the date back - ie a historical date. In fact there is no reason why these things should all be changed at once - a computer might be left on for an hour and then the rest is committed - what is that? > Andrew has also suggested that EHR extracts are really a kind of > "contribution", since they are effectively a bag of TRANSACTIONs to be > applied to en EHR. While the TRANSACTIONs in the EHR_EXTRACT are not > due to the same clinical session (they could be anything, depending on > what the requestor asked for), their addition to the receiving EHR > will in fact be a contribution. This is a merge_audit and I do not think that they have the same status in any way. > If we are to formalise this concept, we need to have use cases showing > when/why contributions need to be handled as explicit entities. > > If we can prove the need, the following architectural possibilities > suggest themselves: > - use FOLDERs to act as contributions, i.e. every time a contribution > goes in, make a new FOLDER that contains the references to those > TRANSACTIONs > - define CONTRIBUTION as a new subtype of FOLDER and use it as above > - if we consider a contribution to be the equivalent of an outer > transaction in a nested transaction, then we might create a new > TRANSACTION for each controbution, whose contents are links to the > other transactions in the contribution, > - we could always add links to the first TRANSACTION in a contribution > pointing to the other TRANSACTIONs in the group. > > thoughts? > NO way Jose - can I be any stronger than that? - Sam - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
