Good info and the criteria makes sense.
I would use episodic for things like hospitalization and treatments that are
not a knee time thing (event), maybe with help of folders. Also I would focus
on intra hospital longitudinal lists since it is very difficult to reach
agreement in the enterprise. And when that time comes, I would just implement a
new set of rules for the enterprise :)
Thanks!
Sent from my LG Mobile
------ Original message------From: Ian McNicollDate: Sat, Apr 2, 2016 15:50To:
For openEHR technical discussions;Subject:Re: Composition commit and change
typesHi Pablo,When I am advising implementers on this, I use the following
categories ...## Composition Commit StylesDepending on the clinical
requirement, 3 styles of commit strategy aresuggested.1. **’Event’**e.g Nursing
observations, clinical encounters, reports.Each time the composition is
committed, create a new instance via a POST.Generally only do a PUT if an error
needs to be corrected2. **’Episodic’**Create a new composition via POST for
each Period of Care i.e anadmission. If it needs to updated, use a PUT to
modify i.e Eachpatient has a single instance per Period of Care.3.
**’Longitudinal’**Create a new composition via POST for each patient. If it
needs toupdated use a PUT to modify i.e. each patient has only a singleinstance
over their lifetime. This will be unusual in a hospitalrecord where there is
generally limited ability to curate the patientrecord in this way.So your
persistence uses cases are either 2/3. Currently to manageEpisodic persistence,
you need ot set the composition category toevent, as the RM currently forces a
'persistent' composition to becontextless i.e. the context attribute is 0...0.
This will change inan upcoming RM revision.The decision about when/where to
maintain persistent/curated lists isone which will vary between
implementations. I would generally expectMedication lists, Allergies and some
documents such as Resuscitationpreferences to be maintained as single,
persistent instances. AlthoughProblems and Procedures should also probably be
maintained that way,there are valid situations where departmental problem lists
e.g Renalmedicine have validity.There are strong arguments, at least in UK
practice, for maintaining asingle cross-organisation outpatient/community
medication record buteach inpatient medication list should be separately
maintianed foreach instiution/episode of care.IanDr Ian McNicollmobile +44
(0)775 209 7859office +44 (0)1536 414994skype: ianmcnicollemail:
[email protected]: @ianmcnicollCo-Chair, openEHR Foundation
[email protected], freshEHR Clinical Informatics Ltd.Director,
HANDIHealth CICHon. Senior Research Associate, CHIME, UCLOn 2 April 2016 at
06:59, [email protected] wrote:> Hi all, I'm testing some cases in the
EHRServer and I want to confirn some> grey areas.>>> If the EHR receives a
commit of a persistent composition and the change type> is creation, should the
EHR create a new composition?>>> i.e. I don't see an EHR having two different
medication lists, is that> possible?>>> I guess persistent compos can only be
created one time per archetype (one> medication list, one problem list, one
vaccination list, etc. per patient),> and after the creation, all commits
should be modification. Does this make> any sense?>>> If this is OK, to avoid
errors from client applications, I would return an> error when a creation is
committed for a persistent compo archetype that> already has a conpo
instance.>>> And about the first commit. Should, lets say, the medication list
be created> when the first medication is recorded or can it be created empty?
What do> other implementations out there do?>>> Thanks a lot!>>>
_______________________________________________> openEHR-technical mailing
list> [email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org_______________________________________________openEHR-technical
mailing
[email protected]http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
