Sam, Is it correct to say that: - Each type of Episode will be an specific Archetype that maps starting at the folder. - What must be communicable generically is the disease type Episode since this can be true in many places. - The Non-disease Archetypes are based on local business rules and don't have to be communicated to others outside the own organization. So each organization will have its own Archetype that fits their business rules. - It will be wise to use in the Archetypes terms that conform to the CEN/TC 251 Continuity of Care standard. - Three proto-Archetypes defining the various episodes must be standardized in order to create interoperability. - Two non disease type proto-archetypes will be highly specialize-able. - The disease related proto-archetype will be of the kind that can not easily be specialized.
New term (=concept): proto-archetype - A standardized Archetype. This proto-archetype must be the starting point for specialization in order to produce an Archetype to be defined and used in a local community. Bye the way. What types of standardized proto-Archetypes will we need? What are the rules for specialization? Which proto-archetypes can and can not be specialized? Or are we more subtle; to what degree? Etc, etc. Do we need accepted rules that govern the production and usage of Archetypes? Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 On 06 Dec 2004, at 03:08, Sam Heard wrote: > Bill and all > > This is a very important consideration and one that we need to get > right for lots of reasons. > > Tom has been proposing an aggregation approach - allowing us to find > all data that relates to something - a disease, care at an institution > etc. > > It is clear that there are aspects of the episode that are specific to > the care setting and administrative and billing requirements. We could > have a composition that held information about the administrative > aspects of the episode....for billing purposes or secondary data > collection. It would be possible to archetype an 'episode' folder to > contain one of these - and possible to define what is held within it > should that be appropriate. > > It is clear that a simple aggregation model is not enough, but we also > do not want to have lots of folders to describe one episode from > different perspectives. > > The Mayo can only have one episode per patient at any time....this > ensures that the person who opens an episode is responsible for > closing it - and summarising it, tying up lose ends etc. This is a > very important quality issue in distributed care environments. But in > the Australian setting where we have primary and secondary care > separated - the notion of secondary care episode is largely a billing > or funding issue - although we have discharge referrals back to > primary care. > > In primary care, the idea of an episode - a single one at a time - is > appealing to me - meaning it is non-routine care for the problems the > person has. It stops what Michael Balint called the "collusion of > anonymity" - a destructive outcome of 'shared' or 'parallel' care. > > Cheers, Sam -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3288 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041206/d0152127/attachment.bin>
