Specification Change Management Plan
Hi everyone, When answering a question from Tony Austin, I ended up at this link : http://www.openehr.org/repositories/spec-dev/latest/publishing/CM/CM_plan/REV_HIST.html (pick the latest version) The question I have is about Chapter 7 & 8 (from now on called document). Is the description of the documennt what will be used for every subproject of openEhr (with subproject in this case I mean project where actually programming takes place) and is this considered a manual for people who want to start programming openEHR like stuff under the umbrella of openehr.org ? What is the goal of the openehr project ? Does it want to something like how Apache works (see http://www.apache.org/foundation/how-it-works.html) or does the openehr project want a different direction ? If it is meant as the apache way and(which is what I read between the lines) and the chapters are the "official way", you should probably change chapter 7 & 8 to be the text of the how it works html file (with some changes of course). Or point to a simple (html) file from the web site describing the process within openehr.org and refer from there for the people interested in reading the chapters 7 & 8. Describing how something should work (related to a community, in this case an open source community), must, in my view be kept simple. If you skim through the document (what I did in the first place, since there was a lot of text), people like me (= who likes to program and never RTFM, unless really necessary) get scared and draw wrong conclusions. Too much formality is scary (at least for people like me) :) Hope no one (esp. Thomas) feels offended, since it is not meant that way. (I admire the way you guys can write specs, if people ask me where my specs are "Read the code" will be my answer). -- Mvgr, Martin - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Modelling Episodes in openEHR
. Remember that a Folder in > openEHR is a reference list, like a little index to particular groups > of Compositions. A given Composition can appear in more than one > Folder. The Folder can be named as being an episode (Folders inherit > "name" from LOCATABLE) and every relevant Composition deemed by the > provider to be in that episode can go in. If a Composition wants to be > included in more than one episode (if you are the kind of provider > that uses the 2nd EN13940 definition above), or in sub-episodes, then > it can. > 2. The Folder when committed to the EHR as part of a Contribution > which causes the EHR Directory to be updated (remember all Folders in > a given EHR are part of the Directory structure), the date of > committal is recorded, as for any openEHR data commit. > 3. A special Composition is defined in an archetype(s) as being > for the purpose of "episode administrative information", and contains > one or more Evaluation type Entries, which provide whatever > administrative details are required for episodes in your > establishment. > 4. When the episode is deemed to have started - which may be > clinically before the creation of the Folder on the EHR system, this > special Composition is created/updated to indicate that date. It might > also have any other descriptive information required for the episode > as a whole. In particular, it could have a data item meaning "state of > episode in time", which could be archetyped to take vocabulary valies > of "initial" (meaning "intended", "scheduled" or whatever), "active", > "closed", "reopened", etc). Date/times could be defined for all of > these, as well as the participants responsible for starting, closing, > reopening the episode. > 5. When the episode is deemed to be closed, the admin Composition > is updated to reflect this. > 6. In this way, the special admin Composition in a Folder > representing an episode always provides the current situation of the > episode in each of its versions. It also means that for querying, > there is only one Composition to search for in episode-Folders, in > order to get the admin data of the episode. > > Currently, Compositions are connected to Folders by a List > in the Folder. It might be useful to use a LINK, which is already > inherited into FOLDER from LOCATABLE, to point to the admin > Composition of an eposide-Folder. This would facilitate querying. > > A second alternative to this scheme is a minro adjustment - instead > of using the versions of a single admin Composition, a number of admin > Compositions could occur within the episode-Folder, each indicating an > act of starting, closing, re-opening, terminating etc, the episode. > Personally I favour the former approach, because it limits the > "special" Compositions in a Folder to just one, and also presents a > simpler picture in versioning terms, but both approaches a clearly > possible, and the second one would be used by systems not implementing > version control at all. > > In summary, we are suggesting a way to use openEHR to accurately and > interoperably represent "episodes", regardless of what your definition > of "episode" may be. The solution requires no changes to openEHR, and > if adopted as the standard approach, means that episode data will be > guaranteed to be interoperable in openEHR, and also provides guidance > for how to represent it in CEN EN13606 EHR Extracts. If this solution > is shown to have no faults and to be workable, we would document as > part of openEHR and publish it. > > Further thoughts & discussion? > > - thomas beale > > ? > - If you have any questions about using this list, please send a > message to d.lloyd at openehr.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 13499 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041204/41d788e6/attachment.bin>
Modelling Episodes in openEHR
lakewood at copper.net wrote: > > From Information Theory it is whatever I choose it to be and the act > of choosing has > no impact upon the original data; it does have an impact on the analysis. > In an object world an episode is derived (inherited) from 'available' > data objects. The derivation > is not original data. > However, should I choose to expand the 'derivation' to include > additional data the results may well > change. we agree with this. By using Folders to delimit episodes, and a special Composition to contain any episode adminitrative data, every institution can include whatever encounters or other data they want in the episode- all you are doing is putting references (pointers) to things, into a Folder, not changing the underlying data. Someone could come along later in the same institution, and define a new kind of episode, and retrospectively create all the Folders for that kind of episode in certain EHRs. This also won't change any of the underlying data. Episode Folders could also be removed, renamed, their references added to or removed - none of this changes any of the data either. > BOTTOM-LINE > As long as the 'original data' is not changed and is made available to > all subsequent accesses, and > others can define their own 'episodes', issues are likely to be move > to the conference room. in which > the background of the episode can be thoroughly reviewed. > > A concern is that dedicating space in an EHR system to handling > episodes , their tracking and their > resolution, not to mention the privacy concerns and accesses by > insurers, may become burdensome. > It it apparent that multi potentially interacting episodes may exist > and there may be no easy > resolution to the lot of them. I think any institution has to have a firm model for what it thinks an episode is - e..g delimited by the points in time when it accepts responsibility for care of a patient to when it divests itself of reponsibility for care (by transfer of care, death, discharge/dismissal). > > Suggest a segmentation of 'episodes' so that they can be readily > identified and isolated. In particular, > episodic data should not be merged with the original data. Their > existance and location should be > sufficient. I believe the Folder-based solution will do all this. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Modelling Episodes in openEHR
Gerard Freriks wrote: > Dear all, > > Am I correct to conclude and propose that: > > - *episode:* situation considered to occupy a time interval > > - there are at least 4 context's in which the term 'Episode' is defined: > disease related (point of view of the patient), this kind of episode often has vague boundaries, and I think we have to rely on following LINKs in the EHR to find all its pieces. If I get bronchitis that seems to get better before it gets worse every two weeks, is this a single episode or many? I don't think it matters - what matters is being able to find all the information items relating to a given problem. > treatment related (point of view healthcare provider), > adminstrative contact related (point of view of healthcare institution), these two are I think possible to identify as being delimited by known points in time, as long as the provider has a clear rule for when they are providing health care, versus when they are not. They might be providing care in parallel with other providers of course - e.g. Dipak had a good example of patients on weekend leave from a mental health institution, who become the responsibility of the local GP for the weekend, but don't really stop being the responsibility of the institution. > insurance related (point of view payer) How re-imbursing institutions want to define episodes is something I don't know much about, but Tim Churches or someone may have something to add here. How does that work in NL, Gerard? I know there is a mixture of government and private payors. > - sometimes the period is real and enumerated (/dd-mm-yy, ISO 8601 : > 1988Data elements and interchange formats - Information interchange - > Representation of dates and times/), > sometimes indefinite (/one week ago, some weeks ago, ongoing, during, > before, etc, as defined in CEN/TC251 EN1238 Time standard for health > care specific problems/) I think such vague times can only be for clinical use (patient had an "episode" of bronchitis about 2 weeks go, lasting about a week). For billing or other computable purposes such as statistical studies, you have to be able to know which things are in and which are out. - thomas - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Specification Change Management Plan
Martin van den Bemt wrote: >Hi everyone, > >When answering a question from Tony Austin, I ended up at this link : >http://www.openehr.org/repositories/spec-dev/latest/publishing/CM/CM_plan/REV_HIST.html >(pick the latest version) > >The question I have is about Chapter 7 & 8 (from now on called >document). > >Is the description of the documennt what will be used for every >subproject of openEhr (with subproject in this case I mean project where >actually programming takes place) and is this considered a manual for >people who want to start programming openEHR like stuff under the >umbrella of openehr.org ? > > not necessarily. This CM plan was originally written mainly for the specification project, and will be adapted for more programming-oriented projects. But implementation projects won't have a very different plan - this plan I wrote based on plans used at a number of companies I have worked at, including banks, British Telecom, and large engineering companies in Australia. >What is the goal of the openehr project ? Does it want to something like >how Apache works (see >http://www.apache.org/foundation/how-it-works.html) >or does the openehr project want a different direction ? > > this page is more or less Apache Software Foundation's change process definition. >If it is meant as the apache way and(which is what I read between the >lines) and the chapters are the "official way", you should probably >change chapter 7 & 8 to be the text of the how it works html file (with >some changes of course). Or point to a simple (html) file from the web >site describing the process within openehr.org and refer from there for >the people interested in reading the chapters 7 & 8. > > this plan is under modification right now actually, and some details will change. We will also publish a simple, clear set of web pages so that people can understand what the process is. The ASF page seems like a good model. >Describing how something should work (related to a community, in this >case an open source community), must, in my view be kept simple. >If you skim through the document (what I did in the first place, since >there was a lot of text), people like me (= who likes to program and >never RTFM, unless really necessary) get scared and draw wrong >conclusions. > >Too much formality is scary (at least for people like me) :) > >Hope no one (esp. Thomas) feels offended, since it is not meant that >way. (I admire the way you guys can write specs, if people ask me where >my specs are "Read the code" will be my answer). > > ah, well, you will discover there are limitations to that approach in the long run (as I am sure you are aware;-) The openEHR community may well get quite large, and we do need to write good quality documents. But we are also dedicated to making things simple and understandable as well - this doesn't mean throwing out our base documents, it means writing short & shart summaries on the website. We need people in the community to tell us what to write (and offer to write things themselves if so motivated), so this is good feedback. - thomas - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Modelling Episodes in openEHR
Thom, It seems we are in agreement. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 04 Dec 2004, at 12:54, Thomas Beale wrote: > Gerard Freriks wrote: > >> Dear all, >> >> Am I correct to conclude and propose that: >> >> - *episode:* situation considered to occupy a time interval >> >> - there are at least 4 context's in which the term 'Episode' is >> defined: >> disease related (point of view of the patient), > > this kind of episode often has vague boundaries, and I think we have > to rely on following LINKs in the EHR to find all its pieces. If I get > bronchitis that seems to get better before it gets worse every two > weeks, is this a single episode or many? I don't think it matters - > what matters is being able to find all the information items relating > to a given problem. > And relating data in a specific context for a specific purpose that some times is defined in a group and sometimes defined by one actor for his own purpose. Episodes likes these are more general and NOT depended on business rules. >> treatment related (point of view healthcare provider), >> adminstrative contact related (point of view of healthcare >> institution), > > these two are I think possible to identify as being delimited by known > points in time, as long as the provider has a clear rule for when they > are providing health care, versus when they are not. They might be > providing care in parallel with other providers of course - e.g. Dipak > had a good example of patients on weekend leave from a mental health > institution, who become the responsibility of the local GP for the > weekend, but don't really stop being the responsibility of the > institution. episodes like these are depended on (local) business rules that vary from place to place. > >> insurance related (point of view payer) > > How re-imbursing institutions want to define episodes is something I > don't know much about, but Tim Churches or someone may have something > to add here. How does that work in NL, Gerard? I know there is a > mixture of government and private payors. I don't know them either. But think of mergers between firms and new insurance products and updates within one firm. > >> - sometimes the period is real and enumerated (/dd-mm-yy, ISO 8601 : >> 1988Data elements and interchange formats - Information interchange - >> Representation of dates and times/), >> sometimes indefinite (/one week ago, some weeks ago, ongoing, during, >> before, etc, as defined in CEN/TC251 EN1238 Time standard for health >> care specific problems/) > > I think such vague times can only be for clinical use (patient had an > "episode" of bronchitis about 2 weeks go, lasting about a week). For > billing or other computable purposes such as statistical studies, you > have to be able to know which things are in and which are out. > I agree. > - thomas > > > > -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3103 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041204/72403de6/attachment.bin>
Specification Change Management Plan
Thanx for the answer I was looking for :) > > > > > this plan is under modification right now actually, and some details > will change. We will also publish a simple, clear set of web pages so > that people can understand what the process is. The ASF page seems like > a good model. I can remove the apache stuff from the page and attach that file to jira, if you want. > > >Describing how something should work (related to a community, in this > >case an open source community), must, in my view be kept simple. > >If you skim through the document (what I did in the first place, since > >there was a lot of text), people like me (= who likes to program and > >never RTFM, unless really necessary) get scared and draw wrong > >conclusions. > > > >Too much formality is scary (at least for people like me) :) > > > >Hope no one (esp. Thomas) feels offended, since it is not meant that > >way. (I admire the way you guys can write specs, if people ask me where > >my specs are "Read the code" will be my answer). > > > > > ah, well, you will discover there are limitations to that approach in > the long run (as I am sure you are aware;-) Don't totally agree here (depends on the area you are talking about). You can probably define 2 set of rules : 1) The meritocracy (as described in the how it all works document) 2) Legal issues 1 almost never fails, although there are scenarios that it does (eg Apache Avalon, but that was mainly clashing ego's and different views on architecture). The main reason this not failing, is the principle : if you veto a decision, you have to explain why, if you don't the veto is void. A veto can happen for votes and for eg commits (commit mails are important at apache, also for being able to have the necessary oversight, hope bitkeeper supports that) Also the main reason everything works "automatically" is that most people have common sense and there is huge degree of trust amongst each other (you have to assume no one is there to mess up everything on purpose) Eg The Episode discussion (assuming I have the proper access to change the specs), I could (technically) simply add the Episode stuff the way I see fit. Since I know you and others now way more about all those stuff, I will automatically discuss this first, before making the change. If I have the attitude "I know it all and I know it better, even though I don't" I will not last long in a community and move away automatically. Most difficult and not to be underestimated is 2, but that is probably for another thread :) If you are interested I can put down some things that are needed, so openehr.org keeps the owner ship of the source code. What is the license you want to use for openehr deliverables (meaning the code) ? > The openEHR community may > well get quite large, and we do need to write good quality documents. > But we are also dedicated to making things simple and understandable as > well - this doesn't mean throwing out our base documents That's why I changed my opinion from removing those chapters to referring to them from the simpler page :) > , it means > writing short & shart summaries on the website. We need people in the > community to tell us what to write (and offer to write things themselves > if so motivated), so this is good feedback. That's the "send a patch" spirit, which is good :) -- Mvgr, Martin - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Modelling Episodes in openEHR
Hi Thomas, Thomas Beale wrote: > > Someone could come along later in the same > institution, and define a new kind of episode, and > retrospectively create all the Folders for that kind > of episode in certain EHRs. This also won't > change any of the underlying data. Episode > Folders could also be removed, renamed, their > references added to or removed - none of this > changes any of the data either. Do you envision this being done manually? Or is there a programmatic solution? The question this thread has raised in my mind is well illustrated by your comment below. > > I think any institution has to have a firm model > for what it thinks an episode is Assuming that different institutions will adopt models that differ, what are the implications for the exchange of data and the creation of a lifelong EHR? Thanks, Bill - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Modelling Episodes in openEHR
The disease episode is about the patient and can and will be exchanged. Other episodes defined on the basis of local business rules will not be exchanged. GF -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 On 04 Dec 2004, at 16:44, Bill Walton wrote: >> >> I think any institution has to have a firm model >> for what it thinks an episode is > > Assuming that different institutions will adopt models that differ, > what are > the implications for the exchange of data and the creation of a > lifelong > EHR? -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 687 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041204/688bece1/attachment.bin>
