Hi Dileep,
it would be interesting if you could publish anything about your virtual
folder design, because more is being added to the RM to standardise how
FOLDERs are used to represent episodes, mainly based on how DIPS
(Norway) and Code24 (NL) do it. See SPECRM-55 and SPECRM-56
<https://openehr.atlassian.net/projects/SPECRM/versions/12516/tab/release-report-all-issues>.
THis is certainly not complete, and indeed we have not yet published a
guide for how to use Folders to do this (there probably is not yet full
agreement anyway). Nevertheless, both these vendors have sophisticated
approaches to using FOLDERs for episodes, and it would be good to have
any other ideas to add to the mix so that we could either standardise a
single approach, or else describe a small number of extant approaches
such that client software can figure out what kind of episode
representation it is dealing with.
ANother thing, just for reference: from a formal point of view, what
gets committed due to an encounter is always be a Contribution, i.e. an
openEHR change set (thinking in DVCS, e.g. Git terms). A Contribution
can contain any / all of:
* completely new TLO(s)
* new version(s) of any existing TLO(s)
* change(s) to any existing TLO(s)
* logical deletion(s) of any TLO(s)
* changes to path structure of any TLO with such a structure (= directory)
Here, TLO = 'top-level object', which can be the following from the EHR
model
<https://specifications.openehr.org/releases/RM/latest/ehr.html#_change_control_in_the_ehr>:
* COMPOSITION
* directory, consisting of FOLDERs
* EHR_STATUS
* EHR_ACCESS
And from the Demographic model
<https://specifications.openehr.org/releases/RM/latest/demographic.html>:
* PARTY
* PARTY_RELATIONSHIP
ANd from the Task Planning model
<https://specifications.openehr.org/releases/PROC/latest/task_planning.html>:
* COMPOSITION containing WORK_PLAN or TASK_PLAN
It is of course very common that the result of an encounter is just one
new COMPOSITION, or one new version of one existing COMPOSITION - but
just as with Git or any other versioning system, this requires a
Contribution since it is still a change set.
Full versioning semantics here
<https://specifications.openehr.org/releases/RM/latest/common.html#_change_control_package>,
for reference.
- thomas
On 05/06/2019 12:15, Dileep V S wrote:
Dear Gerard,
Thanks for your response. Your point of a composition being designed
to record a complete encounter is worth another discussion.
I personally feel that it is one way of implementing your CDR, but
there could be other equally effective approaches that work better in
other situations. For example in the CDR service component of our
platform (EHR.Network), we have gone with generic reusable templates
such as complaints, diagnosis, medication summary, medication order
etc. The application can compose the complete schema for different
encounter/event use cases using a combination of these generic
templates. The data gathered in any event is grouped together under
episodes and events using the virtual folder service.
This approach ensures the generic nature of the platform, while
maintaining it's extensibility over time. It also helps us contain the
proliferation of templates and keeps our library of commonly used
stored queries to a manageable level.
May be there are other better approaches than either of these that are
already being used by others. I feel the approach to choose will
depend upon the requirements and so maintaining flexibility for the
implementer will be crucial.
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
