Hi all,
I'd like to define persistence for a composition dinamically (and not
statically in an archetype), because this property changes depending on
application or application context.
If I'd like to define a composition as persistent, could I define this into
a template? Is this the correct way to use templates? Moreover, in some
particular case, I don't exclude to change persistence attribute for a
compositon at run-time, depending of application context.
Persistent is a feature that has meaning and cannot be changed at runtime.
It means that the data goes on being relevant and does not apply to one
clinical event. It also means that updates are not fixing errors or
incompleteness - they are a new statement of the information. The old data
are not invalidated for the period that was covered.
So you can think of persistent compositions as Managed Lists (current
medications, allergies etc)
Hi Sam,
thanks for your reply. I try to explain which is my issue.
Generally in an application form we can have persistent and not persistent
data. Actually template specifications allow at most one composition in each
template, but this means that a template contains or all persistent data or
all not persistent data.
In order to define template with both persistent and not persistent data, we
should be able to have template with more than one composition. Has anyone
solved this problem?
As the Composition is the transactional unit - the minimum that can be
committed to the health record - the template schema in use at the moment
limits the scope to one composition.
We have used application and screen constructs to have more than one
composition available to the user at one time.
In fact, a commit to the EHR is a contribution and it may be possible to
work at this level in a template. This would mean you could have multiple
compositions in one template.
I will defer to more technical people on the implementation issues.
Hi Tom,
Would this be a template on the EHR_EXTRACT?
Heath
I had not been thinking about that, but that would be an example.
Originally I was thinking of a 'meta-template' that can bind 1 or more
openEHR templates to different data sources, and can then be used more
effectively to generate a screen form.