Gerard Wow.....
> Sam, > > Is it correct to say that: > - Each type of Episode will be an specific Archetype that maps starting > at the folder. As folders can hold symbolic links, compositions can appear in more than one archetype. Folders are the preferred way of aggregating and organising compositions - as that is what they are for. A Folder archetype could limit the type of compositions in a folder, or ensure that particular compositions are present. It is these compositions that will hold information that is particular to the episode - and may have references to particular parts of compositions (data). Some episodes may only require aggregation of compositions and so may be only a folder. > - What must be communicable generically is the disease type Episode > since this can be true in many places. A disease episode is an interesting idea. At the Mayo, an episode is only commenced if someone is getting non-standard care. So a patient may have many diabetic episodes, but only has diabetes once. Aggregating compositions that deal with a particular condition may occur in more than one way... Using Problem/SOAP sections, the problem can be identified and queried against. Using Folders to aggregate compositions that contain any information about a particular problem Using the responsible clinician who has certain qualifications Using the composition type - eg Antenatal visit. So I think this will vary for the time being. It is not necessary that we all do the same thing > - 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. I guess here you mean an administrative episode....I agree. But it is likely that there will be some national reporting requirements in many jurisdictions. > - It will be wise to use in the Archetypes terms that conform to the > CEN/TC 251 Continuity of Care standard. Yes....it will take some work to tease these out - but I agree > - Three proto-Archetypes defining the various episodes must be > standardized in order to create interoperability. proto-archetypes for me are just descriptions of the information space - as in Protege. > - Two non disease type proto-archetypes will be highly specialize-able. Agree - may only have a name in common > - The disease related proto-archetype will be of the kind that can not > easily be specialized. Probably true > > /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./ All archetypes are potentially a starting point for specialisation...but some almost have an 'abstract' quality - such as episode. > Bye the way. > What types of standardized proto-Archetypes will we need? There are some interesting ones potentially..... visualisation is one that I am interested in. To cover external observation and all forms of Xrays, Ultrasound etc. The advantage is that if you are interested in the Liver - it would be easy to find all visualisations - at laparotomy, by ultrasound, CT. The price for such an approach may be too high - but I kind of like the idea of it. Visualisation.ultrasound or visualisation.xray.ctscan > What are the rules for specialization? There are the technical ones that ensure that a specialised archetype does not break the rules of the parent - some of these are working in the editor. Generally, specialisation is appropriate if a query on one archetype should return information even if it is in another. > Which proto-archetypes can and can not be specialized? No rules as yet. > Or are we more subtle; to what degree? Etc, etc. Yes...we are learning a lot about this as we go. > Do we need accepted rules that govern the production and usage of > Archetypes? > We do, and we need to put these together as we go... Sam > 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 > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
