# The concept of contribution **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2002-06-04 10:41 UTC **Views:** 5 **Replies:** 45 **URL:** https://discourse.openehr.org/t/the-concept-of-contribution/14441 --- ## Post #1 by @thomas.beale In the current issue \(3\.11\) of the EHR reference model, we have documented the concept "contribution" as being that collection of TRANSACTIONs corresponding to a single clinical session\. That is to say, due to a patient contact, there could be the following new TRANSACTIONs: \- patient contact \(this causes a new VERSIONED\_TRANSACTION\) \- update to family history transaction \(new version in existing VERSIONED\_TRANSACTION\) \- update to current medications \(new version in existing VERSIONED\_TRANSACTION\) \- update to plan \(new version in existing VERSIONED\_TRANSACTION\) \- etc So the contribution in this case would be four TRANSACTIONs, each in distinct VERSIONED\_TRANSACTIONs, and each having identical details in the CLINICAL\_CONTEXT object\. Now\.\.\. contributions are the unit of change of the record\. The question is, do we need to be able to easily find them after the fact, or is it not really important\. If it is not important most of the time, then we can do nothing, sicne they will in fact be findable by looking for those TRANSACTIONs which have the right CLINICAL\_CONTEXT objects\. However, this will be slow, as it means going through all transactions in the entire record\. If it is important to be able find contributions quickly \(as I have theorised in the past, and Andrew Goodchild at the DSTC suggests\), then we need to formalise the concept\. Andrew has also suggested that EHR extracts are really a kind of "contribution", since they are effectively a bag of TRANSACTIONs to be applied to en EHR\. While the TRANSACTIONs in the EHR\_EXTRACT are not due to the same clinical session \(they could be anything, depending on what the requestor asked for\), their addition to the receiving EHR will in fact be a contribution\. If we are to formalise this concept, we need to have use cases showing when/why contributions need to be handled as explicit entities\. If we can prove the need, the following architectural possibilities suggest themselves: \- use FOLDERs to act as contributions, i\.e\. every time a contribution goes in, make a new FOLDER that contains the references to those TRANSACTIONs \- define CONTRIBUTION as a new subtype of FOLDER and use it as above \- if we consider a contribution to be the equivalent of an outer transaction in a nested transaction, then we might create a new TRANSACTION for each controbution, whose contents are links to the other transactions in the contribution, \- we could always add links to the first TRANSACTION in a contribution pointing to the other TRANSACTIONs in the group\. thoughts? \- thomas beale --- ## Post #2 by @thomas.beale \[Forwarded response from Sam Heard\] Thomas Beale wrote: > In the current issue \(3\.11\) of the EHR reference model, we have documented the concept "contribution" as being that collection of TRANSACTIONs corresponding to a single clinical session\. That is to say, due to a patient contact, there could be the following new TRANSACTIONs: > > \- patient contact \(this causes a new VERSIONED\_TRANSACTION\) > \- update to family history transaction \(new version in existing VERSIONED\_TRANSACTION\) > \- update to current medications \(new version in existing VERSIONED\_TRANSACTION\) > \- update to plan \(new version in existing VERSIONED\_TRANSACTION\) > \- etc > > So the contribution in this case would be four TRANSACTIONs, each in distinct VERSIONED\_TRANSACTIONs, and each having identical details in the CLINICAL\_CONTEXT object\. > > Now\.\.\. contributions are the unit of change of the record\. The question is, do we need to be able to easily find them after the fact, or is it not really important\. If it is not important most of the time, then we can do nothing, sicne they will in fact be findable by looking for those TRANSACTIONs which have the right CLINICAL\_CONTEXT objects\. However, this will be slow, as it means going through all transactions in the entire record\. If it is important to be able find contributions quickly \(as I have theorised in the past, and Andrew Goodchild at the DSTC suggests\), then we need to formalise the concept I do not think that we do but I am happy to hear what people have to say\. I think it is the same function as putting the date back \- ie a historical date\. In fact there is no reason why these things should all be changed at once \- a computer might be left on for an hour and then the rest is committed \- what is that? > Andrew has also suggested that EHR extracts are really a kind of "contribution", since they are effectively a bag of TRANSACTIONs to be applied to en EHR\. While the TRANSACTIONs in the EHR\_EXTRACT are not due to the same clinical session \(they could be anything, depending on what the requestor asked for\), their addition to the receiving EHR will in fact be a contribution\. This is a merge\_audit and I do not think that they have the same status in any way\. > If we are to formalise this concept, we need to have use cases showing when/why contributions need to be handled as explicit entities\. > > If we can prove the need, the following architectural possibilities suggest themselves: > \- use FOLDERs to act as contributions, i\.e\. every time a contribution goes in, make a new FOLDER that contains the references to those TRANSACTIONs > \- define CONTRIBUTION as a new subtype of FOLDER and use it as above > \- if we consider a contribution to be the equivalent of an outer transaction in a nested transaction, then we might create a new TRANSACTION for each controbution, whose contents are links to the other transactions in the contribution, > \- we could always add links to the first TRANSACTION in a contribution pointing to the other TRANSACTIONs in the group\. > > thoughts? > NO way Jose \- can I be any stronger than that? \- Sam --- ## Post #3 by @Mike_Mair Dear Tom, Greetings\. I have been following your work for some time\. It seems we have a great opportunity now to get somewhere with all this, especially with the convergence that you yourself identify in your 'Manifesto' document on the GEHR site\. I mean your concept of 'containers' and 'objects'\. I agree with it, but I was looking to the HL7 CDA to be the basic HES Template, and then the objects \(archetypes\) fit in that\. Bob Dolin from the HL7 Structured Documents Group has described a way of doing this\. Their model might have a different emphasis from your 'versioned transaction' concept\. All 'Health Event Summaries' would have the same basic structure, from simple free text documents to the Level 3 CDAs\. These can then provide a searchable data warehouse\. I have often thought that the distinction between 'persistence' and 'event' transactions was unnecessary\. I don't think we should be constructing an ideal EHR at all\. We should be working on a communication standard\. I agree that a HES or RDS system is not an EHR, but it should not try to be\. Instead, it might provide the currency to make EHRs out of\. That's what vendors are for\. There can also be open source developers\. If we just capture the essentials, in containers of objects from all the health events, that will give all the base data we need\. The HES may start off primitive \(mainly free text\), but will come to contain harvested data objects \(including prescription objects, family history objects etc\.\)\. There will need to be some recognition of different levels of 'grain' in data objects\. I have often found your work confusing on this point\. Blood Pressure \(or intraocular pressure\) will make fine grained data objects\. Whole examinations \(like 'diabetic foot exam'\) are a level of grain coarser\. There is an argument that templates of that level should not be mandated or registered at all, being in the province of the clinician to employ or change as required\. The may in fact be mandated for certain groups, but that is more for administrative control rather than medical virtue\. If you put clinical objects in a standard format basket \(the CDA\), and put the meta data in the header, you can use the header for retrieval and access control\. The standard could be as simple as that\. There could be 'order objects' which might give more context information about how data was captured, but they would be optional\. This concept of the standard would not prevent you from continuing work on your wonderful opensource EHR, and I wish you all success with it, but there are other EHR models, and many as yet undreamed of\. I think the communication 'standard' could and should be simpler as outlined above Regards Mike Mair NZHUG \(NZ HL7 User Group\) > \[Forwarded response from Sam Heard\] > > Thomas Beale wrote: > > > > > In the current issue \(3\.11\) of the EHR reference model, we have > > documented the concept "contribution" as being that collection of > > TRANSACTIONs corresponding to a single clinical session\. That is to > > say, due to a patient contact, there could be the following new > > TRANSACTIONs: > > > > \- patient contact \(this causes a new VERSIONED\_TRANSACTION\) > > \- update to family history transaction \(new version in existing > > VERSIONED\_TRANSACTION\) > > \- update to current medications \(new version in existing > > VERSIONED\_TRANSACTION\) > > \- update to plan \(new version in existing VERSIONED\_TRANSACTION\) > > \- etc > > > > So the contribution in this case would be four TRANSACTIONs, each in > > distinct VERSIONED\_TRANSACTIONs, and each having identical details in > > the CLINICAL\_CONTEXT object\. > > > > Now\.\.\. contributions are the unit of change of the record\. The > > question is, do we need to be able to easily find them after the fact, > > or is it not really important\. If it is not important most of the > > time, then we can do nothing, sicne they will in fact be findable by > > looking for those TRANSACTIONs which have the right CLINICAL\_CONTEXT > > objects\. However, this will be slow, as it means going through all > > transactions in the entire record\. If it is important to be able find > > contributions quickly \(as I have theorised in the past, and Andrew > > Goodchild at the DSTC suggests\), then we need to formalise the concept > > I do not think that we do but I am happy to hear what people have to say\. I --- ## Post #4 by @aniket_Joshi Dear Sir, The concept of "contribution" is definitely 'essential' for the functioninig of an efficient EHR model\. For all practical purposes the memory of the patient and the HCP is in term of "events"\. Each of these "events" have a distinct title for eg\.Appendicectomy and have a number of examinations inside them\. Each examination has a versioned\_transaction as a record\. Thus the event is a cluster of examinations and contribution can act as a cluster of versioned\_transactions with a title\. During retrieval the Health care provider will have to select a contribution after which only the related Versioned\_transactions will have to be retrieved\. Will this reduce the speed? DR ANIKET JOSHI --- ## Post #5 by @thomas.beale I'll preface my comments by stating that after a very useful discussion with Andrew Goodchild today at the DSTC, I have agreed to write up a 2 or 3 page discussion paper on the subject of contributions with diagrams, whch I will put on the web\. This will describe change management of the EHR seen from the configuration management paradigm, and describe what we think a "contribution" really is\. I will publish this in the next couple of days, to help the discussion\.\.\. Mike Mair wrote: > I agree with it, but I was looking to the HL7 CDA to be the basic HES > Template, and then the objects \(archetypes\) fit in that\. Bob Dolin from the > HL7 Structured Documents Group has described a way of doing this\. Their > model might have a different emphasis from your 'versioned transaction' > concept\. All 'Health Event Summaries' would have the same basic structure, > from simple free text documents to the Level 3 CDAs\. These can then provide > a searchable data warehouse\. > It will be searchable at some levels only\. A CDA document is pretty close to what we are calling a contribution\. The differences are: \- with an openEHR contribution, multiple transactions can be updated due to an interaction with the record,\.e\.g family history, plan etc\. This is good from the point of view of having this information in thematically meaningful buckets\. With CDA, all the content is in the document\. If you want to build a picture of family history or current medications or care plan \- especially if you want it nicely arranged under an agreed set of headings \- it is going to be challenging\.\.\. \- due to the level 1,2,3 conformance levels of CDA, any particular query searching for a particular kind of information, e\.g, facts about family history will potentially work well for level 3 documents, but nothing can be said about the level 1 and level 2 documents in the repository, since in general there is no way for the level 3 query to work\. Likewise, queries on level 2 attributes will only work for level 2 and 3 documents; only level 1 queries will correctly return results for all documents\. This is not a criticism \- it is exactly the expected behaviour of a repository of documents whose job is to provide different levels of structuring capability, due to the need to cope with input of varying quality\. Health event summaries appear \(according to our work so far\) to be a relatively easily archetypable family of structures\. Some of their informatino will be what we call "persistent" information, i\.e\. what is found in the persistent transactions \(what I called "thematic" transactions above\)\. > I have often thought that the distinction between 'persistence' and 'event' > transactions was unnecessary\. I don't think we should be constructing an > ideal EHR at all\. We should be working on a communication standard\. I agree > Interestingly, as we work with this concept, it becomes more and more obvious\. Consider the EHR as a repository of documents or information entities, some of which are defined by purpose or theme, such as the typical transactions for "family history", "current meds", "lifestyle", "social history", "vacc history", "therapeutic precautions", "plan", "problem list", etc\. These are what we call persistent transactions, and it is very clear that most EHR applications \- both interactive and batch \- will be hitting these transactions all the time\. In openEHR we are in the business of specifying the semantics of information in health records\. It is true that some of the discussion goes beyond the remit of defining a communication standard\. As long as this is clear, I don't think anyone has a problem with this\. It is formally differentiated by the specification of EHR\_EXTRACT versus EHR \- the former is the basis for communication, while the latter is the basis for systems\. But it is extremely useful to talk about what EHR systems need to be able to do, in order to figure out what the communication model should look like \- I would go so far as to say that no\-one is going to be able to design a good commuication standard without thinking about what is in the systems from which information comes \(others disagree with this but that's the nature of debate\!\) > that a HES or RDS system is not an EHR, but it should not try to be\. > I would agree > Instead, it might provide the currency to make EHRs out of\. That's what > vendors are for\. There can also be open source developers\. If we just > capture the essentials, in containers of objects from all the health events, > that will give all the base data we need\. The HES may start off primitive > \(mainly free text\), but will come to contain harvested data objects > \(including prescription objects, family history objects etc\.\)\. > Interestingly, in discussions at HL7 Atlanta, the gulf between free text and structured information emerged \- there appears to be a much greater free text data problem in the US than elsewhere, presumably due to the transcribing culture there\. Designers of systems in the UK \(Prodigy for example\) would say that a good user interface simply obviates the problem of masses of free text\. In our \(admittedly limited\) GPCG case studies here in Australia \(OASIS, medical director data, sundry others\) we haven't had a problem with struture \- most of the data is structured\. The structure isn't necessarily great, and the challenge has been to "discipline" it according to good archetypes\. So no\-one at this stage has suggested using the CDA for EHR as such\. I'm not saying it could not be used \- maybe when we get more into hospitals we will find it comes into use as a way of getting EHR subissions from legacy applications to an openEHR EHR server\.\.\. > There will need to be some recognition of different levels of 'grain' in > data objects\. I have often found your work confusing on this point\. Blood > Pressure \(or intraocular pressure\) will make fine grained data objects\. > agree \- in openEHR, this is an ENTRY containing a LIST\_S, containing 2 ELEMENTs, each with a value \(if there is a protocol, it is another LIST\_S, with the relevant ELEMENTs for "cuffsize" etc\)\. > Whole examinations \(like 'diabetic foot exam'\) are a level of grain coarser\. > agree \- in openEHR, the heading structure is an ORGANISER\_TREE and ORGANISERs\. > There is an argument that templates of that level should not be > mandated or registered at all, being in the province of the clinician to > employ or change as required\. The may in fact be mandated for certain > groups, but that is more for administrative control rather than medical > virtue\. > Well, whether or not they are mandated as such depends on the specific segment of the clinical community\. This does not mean that they can't exist and shouldn't be used at all\. All we are saying is how to produce them and use them\. Whether they are mandatory is completely up to professional bodies and practitioners agreeing to agree on them\. \(And don't forget \- archetypes are not fixed templates \- you can easily design in the ability to have everything optional, extra trees of information etc\)\. > If you put clinical objects in a standard format basket \(the CDA\), and put > the meta data in the header, you can use the header for retrieval and access > control\. The standard could be as simple as that\. There could be 'order > objects' which might give more context information about how data was > captured, but they would be optional\. > The level 1 header data is nearly the same as the TRANSACTION revision history information in the REVISION\_HISTORY object; we have been working on closing any remaining gaps, but they are very small now\. One thing I will say is that we have tried to base our work on an emerging theory of contexts \(see the "Design Principles for the EHR" document\) rather than ad hoc considerations\. It isn't perfect, but is standing up pretty well to some hard questioning\.\.\. > This concept of the standard would not prevent you from continuing work on > your wonderful opensource EHR, and I wish you all success with it, but there > are other EHR models, and many as yet undreamed of\. I think the > communication 'standard' could and should be simpler as outlined above > I think we are much closer to it than you realise\. Currently in openEHR, an EHR\_EXTRACT, which is what you usually want to transmit consists of: \- the requested TRANSACTIONs \- demographic snapshots for all demographic entities mentioned in the transactions \- access control and other security/consent data \- terminology control data EHR\_EXTRACTs are the unit of request and reply between conformant EHR systems\. The most likely use of a CDA document is from a non\-compliant system \(which may have very little or a lot of structuring\) \_to\_ an EHR system\. The first thing an openEHR system would probably do with it is to pull it apart and apply its information as updates to the relevant transactions\. There may be uses for output as well \- the CDA group would have a better idea of the use cases here\. As for other EHR models, I don't know of too many that aren't particular system models, and I also don't know of many that are based on the notion of clear separation of information representation and knowledge concept models \(i\.e\. reference model and archetypes\)\. Models that I know of include: \- various models from U\. Manchester including Alan Rector's PEN&PAD and others, COSMOS etc \- various models from Switzerland and Holland \- original GEHR \- CEN 13606 and predecessors \- ASTM data set \- various national health data sets, e\.g\. RFA4 \(UK\), GP dataset \(Australia\) \- GCPR model \(US\) \- the Corbamed \(OMG HDTF\) interface specifications \- CDA, which is not a model of the EHR as such, but is certainly related \- open source systems such as Gnumed, Freemed, OSCAR, OIO \(which I admit we haven't spent enough time on\) \- the VHA's Vista system \(which we also have not reviewed as deeply as we should\) Other models which are no less interesting include the InterMountain Health system which we are looking at at the moment, but many of these are not available for review, as they are not standards and are closed\. I'm sure I've missed some important ones here, but one point to remember is: once you go the archetype route \(or any similar 2\-level approach\), many previous models of EHRs are no longer that useful as direct inspiration for the openEHR reference model \(they are however very useful for developing archetypes\)\. \- thomas beale --- ## Post #6 by @thomas.beale aniket Joshi wrote: > Dear Sir, > The concept of "contribution" is definitely > 'essential' for the functioninig of an efficient EHR model\. > For all practical purposes the memory of the patient > and the HCP is in term of "events"\. > Each of these "events" have a distinct title for > eg\.Appendicectomy and have a number of examinations inside them\. > Each examination has a versioned\_transaction as a record\. > Thus the event is a cluster of examinations and > contribution can act as a cluster of > versioned\_transactions with a title\. > it seems to me this use of the word "event" is more what I would call an "episode", i\.e\. a period of time during which a number of related things happen \(e\.g\. admission, examination, operation, review, discharge\)\. The defining aspect of "contribution" we are saying is that it is the unit of change to the EHR \- it is due to a single "clinical session", which might be \- a patient contact \- a set of test results \- the acquisition and merging of an EHR extract or message > During retrieval the Health care provider will have to > select a contribution after which only the related > Versioned\_transactions will have to be retrieved\. > Will this reduce the speed? > DR ANIKET JOSHI > not completely clear on the querying scenario you are proposing here\. \- thomas beale --- ## Post #7 by @Sam Mike Thanks for your letter\. I just want to say something I think is important \- you cannot communicate unless you speak the same language\. We have had HL7 for many years, we have had many other means of communicating information and yet we are unable to communicate EHRs\. This is, in my view, because the information models underlying systems vary so much\. I have seen so many large projects to enable exchange of health information over the years fail \- I know believe that we need to share a basic information model to allow this to take place\. The CDA is a good approach as it uses text as its data layer \- and we can all accept text\. We can even display it with a transform \- which is nice\. The problem is that there is a need to increase the complexity of the information so far beyond text to get true interoperability of EHRs that the text gets very complex and not human readable \- though a transform is still possible to display it\. So, in summary \- we need to have a shared model of the EHR \- implemented in various ways and with greater or lesser transformation required for data and semantic interoperability\. And, text and schema is not enought \- the EHR needs to be expressed primarily within tools that will ensure that the XML is conformant\. I don't expect everyone to agree with this but there is increasing empirical evidence\. Cheers, Sam --- ## Post #8 by @system Hi, A personal view\. HL7 \(V2 and v3\) and CEN messages can be considered fragments of an EHR\. Most often these fragments are used in the logistics of the patient or healthcare provider\. They integrate systems within an organisation\. CEN/TC251, HL7 CDA, GEHR and Structured Reporting \(Dicom\) are efforts to record the information fragments in a document\. A document with the prime goal of registering a narrative based on the fragments\. The narrative of the Healthcare provider telling the medical story of the patient and his problems\. Secondly the narratives in a document must be transferable to other documents\. All the relevant information fragments put together is the EHR\. GEHR, CEN, HL7 CDA and SR provide the syntaxes to tell the story\. The fragments \(including the Terminologies\) are the words\. By adopting all the same syntaxes medical stories become Interoperable provided that the fragments are semantically interoperable\. I consider the Transactions as paragraphs\. And the Contribution the set of paragraphs that are committed \(attested by signing off\) to the record\. Each paragraph has an header and is collected in chapters with a title\. The headers and titles help the navigation and ordering of the information\. Work by CEN and GEHR show that this goal is completely feasible\. HL7 CDA developments are lacking behind because of a predominant focus on CDA level 1 document messages\. With regards, Gerard > Mike > > Thanks for your letter\. I just want to say something I think is important \- > you cannot communicate unless you speak the same language\. We have had HL7 > for many years, we have had many other means of communicating information > and yet we are unable to communicate EHRs\. This is, in my view, because the > information models underlying systems vary so much\. > > I have seen so many large projects to enable exchange of health information > over the years fail \- I know believe that we need to share a basic > information model to allow this to take place\. > > The CDA is a good approach as it uses text as its data layer \- and we can > all accept text\. We can even display it with a transform \- which is nice\. > The problem is that there is a need to increase the complexity of the > information so far beyond text to get true interoperability of EHRs that the > text gets very complex and not human readable \- though a transform is still > possible to display it\. > > So, in summary \- we need to have a shared model of the EHR \- implemented in > various ways and with greater or lesser transformation required for data and > semantic interoperability\. And, text and schema is not enought \- the EHR > needs to be expressed primarily within tools that will ensure that the XML > is conformant\. I don't expect everyone to agree with this but there is > increasing empirical evidence\. > > Cheers, Sam > >> From: owner\-openehr\-technical@openehr\.org >> \[mailto:owner-openehr-technical@openehr.org]On Behalf Of Mike Mair >> Sent: Thursday, 6 June 2002 5:30 AM >> To: Thomas Beale >> Cc: openehr\-technical@openehr\.org >> Subject: Re: The concept of contribution >> >> Dear Tom, >> >> Greetings\. I have been following your work for some time\. It >> seems we have a >> great opportunity now to get somewhere with all this, especially with the >> convergence that you yourself identify in your 'Manifesto' document on the >> GEHR site\. I mean your concept of 'containers' and 'objects'\. >> >> I agree with it, but I was looking to the HL7 CDA to be the basic HES >> Template, and then the objects \(archetypes\) fit in that\. Bob >> Dolin from the >> HL7 Structured Documents Group has described a way of doing this\. Their >> model might have a different emphasis from your 'versioned transaction' >> concept\. All 'Health Event Summaries' would have the same basic structure, >> from simple free text documents to the Level 3 CDAs\. These can >> then provide >> a searchable data warehouse\. >> >> I have often thought that the distinction between 'persistence' >> and 'event' >> transactions was unnecessary\. I don't think we should be constructing an >> ideal EHR at all\. We should be working on a communication >> standard\. I agree >> that a HES or RDS system is not an EHR, but it should not try to be\. >> Instead, it might provide the currency to make EHRs out of\. That's what >> vendors are for\. There can also be open source developers\. If we just >> capture the essentials, in containers of objects from all the >> health events, >> that will give all the base data we need\. The HES may start off primitive >> \(mainly free text\), but will come to contain harvested data objects >> \(including prescription objects, family history objects etc\.\)\. >> >> There will need to be some recognition of different levels of 'grain' in >> data objects\. I have often found your work confusing on this point\. Blood >> Pressure \(or intraocular pressure\) will make fine grained data objects\. >> Whole examinations \(like 'diabetic foot exam'\) are a level of grain >> coarser\. There is an argument that templates of that level should not be >> mandated or registered at all, being in the province of the clinician to >> employ or change as required\. The may in fact be mandated for certain >> groups, but that is more for administrative control rather than medical >> virtue\. >> >> If you put clinical objects in a standard format basket \(the CDA\), and put >> the meta data in the header, you can use the header for retrieval >> and access >> control\. The standard could be as simple as that\. There could be 'order >> objects' which might give more context information about how data was >> captured, but they would be optional\. >> >> This concept of the standard would not prevent you from continuing work on >> your wonderful opensource EHR, and I wish you all success with >> it, but there >> are other EHR models, and many as yet undreamed of\. I think the >> communication >> 'standard' could and should be simpler as outlined above >> >> Regards >> >> Mike Mair >> NZHUG \(NZ HL7 User Group\) >> >> Sent: Wednesday, June 05, 2002 12:17 PM >> Subject: Re: The concept of contribution >> >>> \[Forwarded response from Sam Heard\] >>> >>> Thomas Beale wrote: >>> >>>> In the current issue \(3\.11\) of the EHR reference model, we have >>>> documented the concept "contribution" as being that collection of >>>> TRANSACTIONs corresponding to a single clinical session\. That is to >>>> say, due to a patient contact, there could be the following new >>>> TRANSACTIONs: >>>> >>>> \- patient contact \(this causes a new VERSIONED\_TRANSACTION\) >>>> \- update to family history transaction \(new version in existing >>>> VERSIONED\_TRANSACTION\) >>>> \- update to current medications \(new version in existing >>>> VERSIONED\_TRANSACTION\) >>>> \- update to plan \(new version in existing VERSIONED\_TRANSACTION\) >>>> \- etc >>>> >>>> So the contribution in this case would be four TRANSACTIONs, each in >>>> distinct VERSIONED\_TRANSACTIONs, and each having identical details in >>>> the CLINICAL\_CONTEXT object\. >>>> >>>> Now\.\.\. contributions are the unit of change of the record\. The >>>> question is, do we need to be able to easily find them after the fact, >>>> or is it not really important\. If it is not important most of the >>>> time, then we can do nothing, sicne they will in fact be findable by >>>> looking for those TRANSACTIONs which have the right CLINICAL\_CONTEXT >>>> objects\. However, this will be slow, as it means going through all >>>> transactions in the entire record\. If it is important to be able find >>>> contributions quickly \(as I have theorised in the past, and Andrew >>>> Goodchild at the DSTC suggests\), then we need to formalise the concept >>> >>> I do not think that we do but I am happy to hear what people >> >> have to say\. >> I >>> think it is the same function as putting the date back \- ie a historical >>> date\. In fact there is no reason why these things should all be >> >> changed at >>> once \- a computer might be left on for an hour and then the rest is >>> committed \- what is that? >>> >>>> Andrew has also suggested that EHR extracts are really a kind of >>>> "contribution", since they are effectively a bag of TRANSACTIONs to be >>>> applied to en EHR\. While the TRANSACTIONs in the EHR\_EXTRACT are not >>>> due to the same clinical session \(they could be anything, depending on >>>> what the requestor asked for\), their addition to the receiving EHR >>>> will in fact be a contribution\. >>> >>> This is a merge\_audit and I do not think that they have the >> >> same status in >>> any way\. >>> >>>> If we are to formalise this concept, we need to have use cases showing >>>> when/why contributions need to be handled as explicit entities\. >>>> >>>> If we can prove the need, the following architectural possibilities >>>> suggest themselves: >>>> \- use FOLDERs to act as contributions, i\.e\. every time a contribution >>>> goes in, make a new FOLDER that contains the references to those >>>> TRANSACTIONs >>>> \- define CONTRIBUTION as a new subtype of FOLDER and use it as above >>>> \- if we consider a contribution to be the equivalent of an outer >>>> transaction in a nested transaction, then we might create a new >>>> TRANSACTION for each controbution, whose contents are links to the >>>> other transactions in the contribution, >>>> \- we could always add links to the first TRANSACTION in a contribution >>>> pointing to the other TRANSACTIONs in the group\. >>>> >>>> thoughts? >>>> >>> NO way Jose \- can I be any stronger than that? >>> >>> \- Sam >>> >>> \- >>> If you have any questions about using this list, >>> please send a message to d\.lloyd@openehr\.org >>> >> \- >> If you have any questions about using this list, >> please send a message to d\.lloyd@openehr\.org >> > \- > If you have any questions about using this list, > please send a message to d\.lloyd@openehr\.org \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #9 by @Tim_Benson Gerard, I feel that the idea of the EHR as being essentially a data base made up of bits of messages is a fundamental misconception that is at the bottom of many of our problems in health informatics\. As first approximation it works for GPs but sadly, it does not scale across the whole healthcare spectrum\. Any set structured information is designed for a primary purpose\. This is true of databases, documents, classifications and models\. Any attempt to use that information outside its original purpose is fraught with danger\. While it is true that a collection of documents can be thought of as an electronic record, we have to take a lot of care when the information which they contain is reused outside the original context of a message\. CEN and HL7 messages are just that \- messages \- from someone, to someone and about someone at a moment in time\. They have more in common with electronic mail than with database structures\. Any attempt to take information from a message and put it into a database is potentially dangerous and needs to be done with a real understanding of the data\. This can only be done when messages are rooted in very clearly defined use cases\. The scale of the problem is illustrated by thinking very clearly about ALL of the potential users of medical records\. In UK the Dept of Health recognises more than 60 medical specialties\. If you add in all of the other clinical specialties then you have at least 100 distinct groups of people who have their own specialised ways of working and requirements, including audit and quality control issues, which ultimately determine how they need their data to be structured\. They cannot all use just one structure, however much we would like this to be the case\. Kind regards Tim --- ## Post #10 by @system > Gerard, > > I feel that the idea of the EHR as being essentially a data base made up of > bits of messages is a fundamental misconception that is at the bottom of > many of our problems in health informatics\. As first approximation it works > for GPs but sadly, it does not scale across the whole healthcare spectrum\. >>>> \\ Tim, I agree with you\. Messages used in logistics are messages used for logistics\. The EHR is about narration\. > Any set structured information is designed for a primary purpose\. This is > true of databases, documents, classifications and models\. Any attempt to > use that information outside its original purpose is fraught with danger\. > While it is true that a collection of documents can be thought of as an > electronic record, we have to take a lot of care when the information which > they contain is reused outside the original context of a message\. > > CEN and HL7 messages are just that \- messages \- from someone, to someone and > about someone at a moment in time\. They have more in common with electronic > mail than with database structures\. Any attempt to take information from a > message and put it into a database is potentially dangerous and needs to be > done with a real understanding of the data\. This can only be done when > messages are rooted in very clearly defined use cases\. >>>>> I want to separate CEN from HL7\. With CEN we focus on Documents with narrative in a structured form either stored or transported between persons\. HL7 \(v2 and v3\) are about messages exchanged between databases for logistics purposes\. They contain no real narrative\. > The scale of the problem is illustrated by thinking very clearly about ALL > of the potential users of medical records\. In UK the Dept of Health > recognises more than 60 medical specialties\. If you add in all of the other > clinical specialties then you have at least 100 distinct groups of people > who have their own specialised ways of working and requirements, including > audit and quality control issues, which ultimately determine how they need > their data to be structured\. They cannot all use just one structure, > however much we would like this to be the case\. > >>> Next to the many types of users there are 10\-20 different functions of any EHR\. > Kind regards > > Tim \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #11 by @Tim_Benson > From: Gerard Freriks <gfrer@luna\.nl> > Date: Fri, 07 Jun 2002 21:46:28 \+0200 > > I want to separate CEN from HL7\. With CEN we focus on Documents with > narrative in a structured form either stored or transported between persons\. > HL7 \(v2 and v3\) are about messages exchanged between databases for logistics > purposes\. They contain no real narrative\. This comment seems to point to a mis\-conception about what HL7 is doing now and what CEN has achieved over the past 10 years\. Most existing HL7 implementations could be described as logistical, but the same is equally true of CEN implementations\. Indeed the work has proceded in parallel with a good deal of duplication of effort\. It is quite wrong to characterize the present work of HL7 as being "for logistics purposes" only\. HL7 has about 30 different technical committees and special interest groups, and while some do have a logistical focus, many do not\. The scope is so wide that few people have a full overview of all the work that is going on\. I am not quite sure that I understand why you focus on the narrative perspective as being so crucial\. Ideas about story\-telling and narratology have been useful in understanding some of the ways in which GPs in particular use \(and misuse\) medical records, but they only illustrate one of the ways in which records are used \(and these are mostly the ones where computability is least important\)\. The primary use of narrative to to provide something that can be understood by a human being, while the value of structure is to have something that is computable\. It is quite easy to produce a medical record which meets these requirements for a SINGLE group of users \(such as GPs\), but it is a different thing altogether to solve the problem for MULTIPLE groups\. It is not the narrative that creates the problem, but the structure\. Most structures use a version of a tree\-like hierarchy, which can only support one perspective\. The way forward is to use structures which support MANY different hierarchical structures at the same time\. The key word above is MANY\. Existing systems support several ways of looking at a medical record\. Indeed the Abies GP system of 15 years ago allowed the user to view the record according to different types of date, by patient problem and by about 20 pre\-defined characteristics \(medication, diagnoses etc\) and by groups of coded entries \(using the Read Code hierarchy\)\. Indeed the indexes for any medical record contained perhaps ten time as many entries as the record itself\. This worked rather well for GPs, but did not migrate too well into secondary care, where there are multiple and conflicting ways that different groups wanted to look at the data\. The solution to this problem is the evolution of virtual records for each group of users, based on their own specific use cases\. But this has little to do with narrative\.\.\. Kind regards Tim --- ## Post #12 by @thomas.beale Tim Benson wrote: > Gerard, > > CEN and HL7 messages are just that \- messages \- from someone, to someone and > about someone at a moment in time\. They have more in common with electronic > actually, you have to be careful \- CEN messages are closer to this idea; HL7 messages are mostly from machine to machine\. > mail than with database structures\. Any attempt to take information from a > message and put it into a database is potentially dangerous and needs to be > done with a real understanding of the data\. This can only be done when > messages are rooted in very clearly defined use cases\. > Agree \- this whole problem was one reason I wrote the "Health Information Standards Manifesto" > The scale of the problem is illustrated by thinking very clearly about ALL > of the potential users of medical records\. In UK the Dept of Health > recognises more than 60 medical specialties\. If you add in all of the other > clinical specialties then you have at least 100 distinct groups of people > who have their own specialised ways of working and requirements, including > audit and quality control issues, which ultimately determine how they need > their data to be structured\. They cannot all use just one structure, > however much we would like this to be the case\. > Well here I no longer agree\. I agree if we are still using the "old way" of doing things \- building a huge model of everything and turning it into software and databases\. But as soon as you take the approach that the information is instances of lego bricks, the model is a model of lego bricks, and the particular configurations of lego bricks are defined by domain concept models \- which are developed independently of the software and databases \- this argument no longer holds water\. I see no impediment whatever to to EHR systems which serves all types of users, as long as it is built on this architectural premise\. And this premise is also the key to interoperabiity of data \_between\_ specialisations\. \- thomas beale --- ## Post #13 by @thomas.beale Gerard Freriks wrote: > I want to separate CEN from HL7\. With CEN we focus on Documents with > narrative in a structured form either stored or transported between persons\. > HL7 \(v2 and v3\) are about messages exchanged between databases for logistics > purposes\. They contain no real narrative\. > This last statement is important \- most HL7 messages are not likely to be the result or recording the dialogue of clinician/patient, or the clinician's own thinking; they are about recording intended/proposed/occurred events in the system, i\.e\. as Gerard says, logistical messages\. These are two different functions, and if this is not understood properly, the industry is indeed going to have a hard time a\) knowing how to use standards and b\) knowing how to build systems\. \- thomas beale --- ## Post #14 by @Mike_Mair Thanks Sam, You said: you cannot communicate unless you speak the same language\. We have had HL7 > for many years, we have had many other means of communicating information > and yet we are unable to communicate EHRs\. This is, in my view, because the > information models underlying systems vary so much\. There are so many ontologies, and more being invented all the time\. I agree that you need to share some to communicate, but that can be negotiated\. The reality we have to deal with is polyontology, and there are tools being developed to navigate between them\. \(eg the Ontology Inference Layer OIL and DAML http://www.daml.org/ \) > The CDA is a good approach as it uses text as its data layer \- and we can > all accept text\. We can even display it with a transform \- which is nice\. > The problem is that there is a need to increase the complexity of the > information so far beyond text to get true interoperability of EHRs If we start by sharing the CDA as HES, we can migrate to more structured data sharing as the level 2\-3 CDA is developed\. We are not trying for full interoperability between EHRs at this stage \- too hard\! We can start simple and grow into more complete interoperability with further iterations both of the standard, and participant software\. > \- we need to have a shared model of the EHR \- implemented in > various ways and with greater or lesser transformation required for data and > semantic interoperability\. Why not just limit the 'standard' to dictionaries of archetypes \(informed by ontologies\), and containers to convey them\. We can use the access control and document navigaton features of the CDA to convey the clinical objects harvested at the health event\. The level 2\-3 CDA is a hybrid, part document, part container\. A Health Event Summary, a Transaction, a EHR Extract, and a CDA document have very similar properties, including 'Persistence, Stewardship, Wholeness, and human readiablity' \(from the CDA specs\)\. Standards work is about achieving a shared way of doing something, so if we all just adopt this 'low hanging fruit' the 'standard' will be served\. There's work enough to do to get a shared design for the clinical objects\. Thomas Beale suggests that the CDA might have a role integrating legacy systems into his EHR, which might be fine if the rest of us are 'legacy'\. We can use the CDA for our baseline interoperability between all systems including GEHR systems\. < text and schema is not enough \- the EHR > needs to be expressed primarily within tools that will ensure that the XML > is conformant\. I don't expect everyone to agree with this but there is > increasing empirical evidence\. The question is, whose ontology, whose schemas, and that's just where we are at\. I think it is time to actually get the specs for clinical objects, and start making some dictionaries, incorporating work already done, eg the 3M work, the GEHR archetypes, Dicom objects etc\. However,it is possible there will be many ontologies even for clinical material\. I note that the technique of Natural Language Processing is being applied to medical free text especially in the US, delivering a dictionary of medical 'facts' \.\. These would be a source of structured data and the CDA could be an exchange format for documents that are secondarily 'structured' in this way\. This would generate more work for ontology integration tools\! We might get to a situation more like Natural Language, where 'meaning is use', and terms come into existence, mutate, pass out of use, yet still mange to 'mean' for their participant communities\. I am still not convinced that it is an EHR structure that has to be shared for meaningful communication\. Both aspects of interoperabiliy, functional and semantic, can be served without sharing an EHR structure\. Regards Mike Mair \(NZ HL7 User Group\) > > From: http://www.daml.org/ > > \[mailto:owner-openehr-technical@openehr.org]On Behalf Of Mike Mair > > Sent: Thursday, 6 June 2002 5:30 AM > > To: Thomas Beale > > Cc: openehr\-technical@openehr\.org > > Subject: Re: The concept of contribution > > > > > > Dear Tom, > > > > Greetings\. I have been following your work for some time\. It > > seems we have a > > great opportunity now to get somewhere with all this, especially with the > > convergence that you yourself identify in your 'Manifesto' document on the > > GEHR site\. I mean your concept of 'containers' and 'objects'\. > > > > I agree with it, but I was looking to the HL7 CDA to be the basic HES > > Template, and then the objects \(archetypes\) fit in that\. Bob > > Dolin from the > > HL7 Structured Documents Group has described a way of doing this\. Their > > model might have a different emphasis from your 'versioned transaction' > > concept\. All 'Health Event Summaries' would have the same basic structure, > > from simple free text documents to the Level 3 CDAs\. These can > > then provide > > a searchable data warehouse\. > > > > I have often thought that the distinction between 'persistence' > > and 'event' > > transactions was unnecessary\. I don't think we should be constructing an > > ideal EHR at all\. We should be working on a communication > > standard\. I agree > > that a HES or RDS system is not an EHR, but it should not try to be\. > > Instead, it might provide the currency to make EHRs out of\. That's what > > vendors are for\. There can also be open source developers\. If we just > > capture the essentials, in containers of objects from all the > > health events, > > that will give all the base data we need\. The HES may start off primitive > > \(mainly free text\), but will come to contain harvested data objects > > \(including prescription objects, family history objects etc\.\)\. > > > > There will need to be some recognition of different levels of 'grain' in > > data objects\. I have often found your work confusing on this point\. Blood > > Pressure \(or intraocular pressure\) will make fine grained data objects\. > > Whole examinations \(like 'diabetic foot exam'\) are a level of grain > > coarser\. There is an argument that templates of that level should not be > > mandated or registered at all, being in the province of the clinician to > > employ or change as required\. The may in fact be mandated for certain > > groups, but that is more for administrative control rather than medical > > virtue\. > > > > If you put clinical objects in a standard format basket \(the CDA\), and put > > the meta data in the header, you can use the header for retrieval > > and access > > control\. The standard could be as simple as that\. There could be 'order > > objects' which might give more context information about how data was > > captured, but they would be optional\. > > > > This concept of the standard would not prevent you from continuing work on > > your wonderful opensource EHR, and I wish you all success with > > it, but there > > are other EHR models, and many as yet undreamed of\. I think the > > communication > > 'standard' could and should be simpler as outlined above > > > > Regards > > > > Mike Mair > > NZHUG \(NZ HL7 User Group\) > > > > Sent: Wednesday, June 05, 2002 12:17 PM > > Subject: Re: The concept of contribution > > > > > > > \[Forwarded response from Sam Heard\] > > > > > > Thomas Beale wrote: > > > > > > > > > > > In the current issue \(3\.11\) of the EHR reference model, we have > > > > documented the concept "contribution" as being that collection of > > > > TRANSACTIONs corresponding to a single clinical session\. That is to > > > > say, due to a patient contact, there could be the following new > > > > TRANSACTIONs: > > > > > > > > \- patient contact \(this causes a new VERSIONED\_TRANSACTION\) > > > > \- update to family history transaction \(new version in existing > > > > VERSIONED\_TRANSACTION\) > > > > \- update to current medications \(new version in existing > > > > VERSIONED\_TRANSACTION\) > > > > \- update to plan \(new version in existing VERSIONED\_TRANSACTION\) > > > > \- etc > > > > > > > > So the contribution in this case would be four TRANSACTIONs, each in > > > > distinct VERSIONED\_TRANSACTIONs, and each having identical details in > > > > the CLINICAL\_CONTEXT object\. > > > > > > > > Now\.\.\. contributions are the unit of change of the record\. The > > > > question is, do we need to be able to easily find them after the fact, > > > > or is it not really important\. If it is not important most of the > > > > time, then we can do nothing, sicne they will in fact be findable by > > > > looking for those TRANSACTIONs which have the right CLINICAL\_CONTEXT > > > > objects\. However, this will be slow, as it means going through all > > > > transactions in the entire record\. If it is important to be able find > > > > contributions quickly \(as I have theorised in the past, and Andrew > > > > Goodchild at the DSTC suggests\), then we need to formalise the concept > > > > > > > > > I do not think that we do but I am happy to hear what people > > have to say\. > > I > > > think it is the same function as putting the date back \- ie a historical > > > date\. In fact there is no reason why these things should all be > > changed at > > > once \- a computer might be left on for an hour and then the rest is > > > committed \- what is that? > > > > > > > > > > Andrew has also suggested that EHR extracts are really a kind of > > > > "contribution", since they are effectively a bag of TRANSACTIONs to be > > > > applied to en EHR\. While the TRANSACTIONs in the EHR\_EXTRACT are not > > > > due to the same clinical session \(they could be anything, depending on > > > > what the requestor asked for\), their addition to the receiving EHR > > > > will in fact be a contribution\. > > > > > > > > > This is a merge\_audit and I do not think that they have the > > same status in > > > any way\. > > > > > > > > > > If we are to formalise this concept, we need to have use cases showing > > > > when/why contributions need to be handled as explicit entities\. > > > > > > > > If we can prove the need, the following architectural possibilities > > > > suggest themselves: > > > > \- use FOLDERs to act as contributions, i\.e\. every time a contribution > > > > goes in, make a new FOLDER that contains the references to those > > > > TRANSACTIONs > > > > \- define CONTRIBUTION as a new subtype of FOLDER and use it as above > > > > \- if we consider a contribution to be the equivalent of an outer > > > > transaction in a nested transaction, then we might create a new > > > > TRANSACTION for each controbution, whose contents are links to the > > > > other transactions in the contribution, > > > > \- we could always add links to the first TRANSACTION in a contribution --- ## Post #15 by @Tim_Benson > From: "Mike Mair" <mikemair@es\.co\.nz> > I am still not convinced that it is an EHR structure that has to be shared > for meaningful communication\. Both aspects of interoperabiliy, functional > and semantic, can be served without sharing an EHR structure\. Mike \- I agree with you here\. Yes, interoperability depends on using a common architecture for the information objects which are exchanged, but this architecture can and should be both technology and domain independent\. Modern software development practice \(e\.g\. UP\) suggests that we distinguish between specifications for requirements, design and implementation\. Requirements specifications are domain specific \(use case and business information models\), Design specifications are ideally a realisation of the requirements using a domain independent and technology independent architecture; and Implementation is a technology specific realisation of the design\. A domain independent reference architecture \(such as the HL7 RIM\) enables reuse across domains, while technology independence enables implementation across channels and is more future\-proof\. In my view, work on EHR standards should focus most attention on use case and business information models, which is where the EHR\-specific complexity lies\. The different use cases for EHRs can be realised using an interoperability architecture \(such as the RIM\) and implemented using a variety of technologies and channels \(browsers, PDAs etc\)\. One of our most common mistakes is to start from the technology and work backwards\. This is especially hard to resist when you have already committed to using a particular technology\! However, standards must be technology neutral\. Tim --- ## Post #16 by @system Dear William, I don't object to quoting me\. But I do object to your interpretation\. 'Shortcomings of HL7' It is NOT a 'shortcoming of HL7 and the RIM'\. HL7 messages a very successful in standardising messages that exchange information between systems so these systems can be integrated\. These messages contain factual information: a lab test, an order, an admission\. All this is not a shortcoming of HL7\. HL7 v2 is a success\. The RIM of HL7 v3 is a \(partial\) success\. The concept is excellent\. Interoperability on a large scale needs a meta\-model\. Talking about 'shortcomings'\. Helas the Rim is not stabile, yet\. It will not become a formal part of the normative standard\. And then it is to much a mixture of IT specific parts and Healthcare specific parts\. The HL7 method has shortcomings because the mapping of the R\-MIM onto the RIM is done by hand\. This will create inconsistencies between different groups producing them\. Finally HL7 creates messages which content \(dataset\) is part of the standard to be used all over the world\. The standardised message will be to inflexible and to generic\. Because you didn't understand my comments I will try again\. I see communication \(interoperability\) take place on two levels\. 1\- Between machines in order to integrate them within an organisation\. The messages update databases\. The messages don't contain narrative\. They contain factual data\. \(a lab\-order, a lab result, etc\) This type of information exchange is essential\. 2\- Between persons or between the author and his record\. This type of registration \(Document, EHR\) takes place on the basis of the data that are communicated in messages\. But it is not about facts only, but about the medical story of a patient as perceived by the narrator \(healthcare provider\)\. The essence is that facts are interpreted as objective as possible but always it will be the subjective interpretation of the author\. It contains the professional opinion based on the recorded facts\. Because the EHR must not be communicated but instantiated in a system, the Model on which it is based will different from a model to be used for communication only\. This type of information exchange is essential, also\. With CEN/TC251 we co\-operate with GEHR\-Australia\. As much as possible we will align \(harmonise\) with HL7\. We will have our own Reference Model\. But an Archetype Model as well\. Together with the Archetype editor \(containing all the rules of the method\) the collection of the Archetypes that user communities will use form the HL7 R\-MIM equivalent\. But will be very adaptable to local needs and stay consistent with the Reference Model and rules\. Messages are primarily the turf of HL7 v2\. I know that HL7 is working on Structured Documents\. Documents are primarily the turf of CEN/TC251 \- GEHR\. CEN has messages as well\. In short\. HL7 is for system integration within one organisation using messages\. It is about objective facts\. CEN is for people integration between separate organisations using the document or record\. It is about narrative\. The above is the most concise way to inform you of my opinion\. See you in Australia\. With regards Gerard > Gerard, >     Do you mind if I quote some of your comments about the shortcomings > of HL7 and the RIM to the AMIA EHR group\. We have established an EHR > initiavtive and I am trying to represent a broader existing status quo\. I > then will assign a group to access the statements, and we will publish our > conclusions\. I would be willing to share that published results\. > > I have had some difficulty in understanding the comments\. The definition > of narrative and structured data seem to be different than mine\. I am > particularly interested in what you propose as an alternative and what the > time line might be\. > > Thanks > > Ed Hammond > \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #17 by @system Dear Tim, I know that I painted things black and white\. But my picture contains some truth's, I think\. The scope of CEN and HL7 is not completely overlapping\. HL7 concentrated more or systems integration within an institutions\. And CEN more on exchange of information between organisations\. The last couple of years CEN moved towards Documents instead of messages\. Plus CEN started to standardise message components\. Lego bricks\. My focus on narrative texts \(the EHR\) is obvious\. In medicine physicians exchange more than objective information and give orders\. They narrate the medical story of their patient, their thoughts and deliberations about all the objective events that all constitute the EHR\. It is a personal account of a journey travelled together by the patient, its relatives, and the healthcare provider\. In general it is NOT a narrative to be shared by many\. The medical record is a personal, subjective document\. It is a narrative for personal usage\. When information is to be shared the author will select and rewrite parts of his notes in order to meet a specific request by an other healthcare provider\. This is the way people work\. This is the way healthcare providers know how to work with using paper systems\. I can see that objective information \(orders, test results\) can be shared by all without real problems\. But people \(good healthcare\) will need subjective narrative as recorded in their personal Medical Records\. Personally I don't believe in one all encompassing, fulfilling all needs for all, Medical Record shared by all; now and in the future\. Gerard >> From: Gerard Freriks <gfrer@luna\.nl> >> Date: Fri, 07 Jun 2002 21:46:28 \+0200 >> >> I want to separate CEN from HL7\. With CEN we focus on Documents with >> narrative in a structured form either stored or transported between persons\. >> HL7 \(v2 and v3\) are about messages exchanged between databases for logistics >> purposes\. They contain no real narrative\. > > This comment seems to point to a mis\-conception about what HL7 is doing now > and what CEN has achieved over the past 10 years\. Most existing HL7 > implementations could be described as logistical, but the same is equally > true of CEN implementations\. Indeed the work has proceded in parallel with > a good deal of duplication of effort\. > > It is quite wrong to characterize the present work of HL7 as being "for > logistics purposes" only\. HL7 has about 30 different technical committees > and special interest groups, and while some do have a logistical focus, many > do not\. The scope is so wide that few people have a full overview of all > the work that is going on\. > > I am not quite sure that I understand why you focus on the narrative > perspective as being so crucial\. Ideas about story\-telling and narratology > have been useful in understanding some of the ways in which GPs in > particular use \(and misuse\) medical records, but they only illustrate one of > the ways in which records are used \(and these are mostly the ones where > computability is least important\)\. The primary use of narrative to to > provide something that can be understood by a human being, while the value > of structure is to have something that is computable\. > > It is quite easy to produce a medical record which meets these requirements > for a SINGLE group of users \(such as GPs\), but it is a different thing > altogether to solve the problem for MULTIPLE groups\. It is not the > narrative that creates the problem, but the structure\. Most structures use > a version of a tree\-like hierarchy, which can only support one perspective\. > The way forward is to use structures which support MANY different > hierarchical structures at the same time\. > > The key word above is MANY\. Existing systems support several ways of > looking at a medical record\. Indeed the Abies GP system of 15 years ago > allowed the user to view the record according to different types of date, by > patient problem and by about 20 pre\-defined characteristics \(medication, > diagnoses etc\) and by groups of coded entries \(using the Read Code > hierarchy\)\. Indeed the indexes for any medical record contained perhaps ten > time as many entries as the record itself\. This worked rather well for GPs, > but did not migrate too well into secondary care, where there are multiple > and conflicting ways that different groups wanted to look at the data\. The > solution to this problem is the evolution of virtual records for each group > of users, based on their own specific use cases\. But this has little to do > with narrative\.\.\. > > Kind regards > > Tim \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #18 by @system Mike, Why the focus on HL7 only? CEN/TC251 has started work on the EN 13606 and is precisely what you want\. HL7 version 3 and CDA will be to unstable for some time to come\. HL7 doesn't adopt the GEHR \(CEN\) two model approach\. Artefacts based on the present HL7 version 3 RIM will prove to be unimplementable as a system or object\. It is my opinion that a real co\-operation between HL7 CDA and CEN/TC251 TF EN 13606 is of importance\. CEN and GEHR have a lot to offer to HL7\. But will this be recognised? Gerard > Thanks Sam, > > You said: > > you cannot communicate unless you speak the same language\. We have had HL7 >> for many years, we have had many other means of communicating information >> and yet we are unable to communicate EHRs\. This is, in my view, because > > the >> information models underlying systems vary so much\. > > There are so many ontologies, and more being invented all the time\. I agree > that you need to share some to communicate, but that can be negotiated\. The > reality we have to deal with is polyontology, and there are tools being > developed to navigate between them\. \(eg the Ontology Inference Layer OIL and > DAML http://www.daml.org/ \) > >> The CDA is a good approach as it uses text as its data layer \- and we can >> all accept text\. We can even display it with a transform \- which is nice\. >> The problem is that there is a need to increase the complexity of the >> information so far beyond text to get true interoperability of EHRs > > If we start by sharing the CDA as HES, we can migrate to more structured > data sharing as the level 2\-3 CDA is developed\. We are not trying for full > interoperability between EHRs at this stage \- too hard\! We can start simple > and grow into more complete interoperability with further iterations both of > the standard, and participant software\. >> > > \- we need to have a shared model of the EHR \- implemented in >> various ways and with greater or lesser transformation required for data > > and >> semantic interoperability\. > > Why not just limit the 'standard' to dictionaries of archetypes \(informed by > ontologies\), and containers to convey them\. We can use the access control > and document navigaton features of the CDA to convey the clinical objects > harvested at the health event\. The level 2\-3 CDA is a hybrid, part document, > part container\. A Health Event Summary, a Transaction, a EHR Extract, and > a CDA document have very similar properties, including 'Persistence, > Stewardship, Wholeness, and human readiablity' \(from the CDA specs\)\. > Standards work is about achieving a shared way of doing something, so if we > all just adopt this 'low hanging fruit' the 'standard' will be served\. > > There's work enough to do to get a shared design for the clinical objects\. > Thomas Beale suggests that the CDA might have a role integrating legacy > systems into his EHR, which might be fine if the rest of us are 'legacy'\. We > can use the CDA for our baseline interoperability between all systems > including GEHR systems\. > > < text and schema is not enough \- the EHR >> needs to be expressed primarily within tools that will ensure that the XML >> is conformant\. I don't expect everyone to agree with this but there is >> increasing empirical evidence\. > > The question is, whose ontology, whose schemas, and that's just where we > are at\. I think it is time to actually get the specs for clinical objects, > and start making some dictionaries, incorporating work already done, eg the > 3M work, the GEHR archetypes, Dicom objects etc\. However,it is possible > there will be many ontologies even for clinical material\. I note that the > technique of Natural Language Processing is being applied to medical free > text especially in the US, delivering a dictionary of medical 'facts' \.\. > These would be a source of structured data and the CDA could be an exchange > format for documents that are secondarily 'structured' in this way\. This > would generate more work for ontology integration tools\! > > We might get to a situation more like Natural Language, where 'meaning is > use', and terms come into existence, mutate, pass out of use, yet still > mange to 'mean' for their participant communities\. > > I am still not convinced that it is an EHR structure that has to be shared > for meaningful communication\. Both aspects of interoperabiliy, functional > and semantic, can be served without sharing an EHR structure\. > > Regards > > Mike Mair \(NZ HL7 User Group\) > >>> From: http://www.daml.org/ >>> \[mailto:owner-openehr-technical@openehr.org]On Behalf Of Mike Mair >>> Sent: Thursday, 6 June 2002 5:30 AM >>> To: Thomas Beale >>> Cc: openehr\-technical@openehr\.org >>> Subject: Re: The concept of contribution >>> >>> Dear Tom, >>> >>> Greetings\. I have been following your work for some time\. It >>> seems we have a >>> great opportunity now to get somewhere with all this, especially with > > the >>> convergence that you yourself identify in your 'Manifesto' document on > > the >>> GEHR site\. I mean your concept of 'containers' and 'objects'\. >>> >>> I agree with it, but I was looking to the HL7 CDA to be the basic HES >>> Template, and then the objects \(archetypes\) fit in that\. Bob >>> Dolin from the >>> HL7 Structured Documents Group has described a way of doing this\. Their >>> model might have a different emphasis from your 'versioned transaction' >>> concept\. All 'Health Event Summaries' would have the same basic > > structure, >>> from simple free text documents to the Level 3 CDAs\. These can >>> then provide >>> a searchable data warehouse\. >>> >>> I have often thought that the distinction between 'persistence' >>> and 'event' >>> transactions was unnecessary\. I don't think we should be constructing an >>> ideal EHR at all\. We should be working on a communication >>> standard\. I agree >>> that a HES or RDS system is not an EHR, but it should not try to be\. >>> Instead, it might provide the currency to make EHRs out of\. That's > > what >>> vendors are for\. There can also be open source developers\. If we just >>> capture the essentials, in containers of objects from all the >>> health events, >>> that will give all the base data we need\. The HES may start off > > primitive >>> \(mainly free text\), but will come to contain harvested data objects >>> \(including prescription objects, family history objects etc\.\)\. >>> >>> There will need to be some recognition of different levels of 'grain' in >>> data objects\. I have often found your work confusing on this point\. > > Blood >>> Pressure \(or intraocular pressure\) will make fine grained data objects\. >>> Whole examinations \(like 'diabetic foot exam'\) are a level of grain >>> coarser\. There is an argument that templates of that level should not be >>> mandated or registered at all, being in the province of the clinician to >>> employ or change as required\. The may in fact be mandated for certain >>> groups, but that is more for administrative control rather than medical >>> virtue\. >>> >>> If you put clinical objects in a standard format basket \(the CDA\), and > > put >>> the meta data in the header, you can use the header for retrieval >>> and access >>> control\. The standard could be as simple as that\. There could be 'order >>> objects' which might give more context information about how data was >>> captured, but they would be optional\. >>> >>> This concept of the standard would not prevent you from continuing work > > on >>> your wonderful opensource EHR, and I wish you all success with >>> it, but there >>> are other EHR models, and many as yet undreamed of\. I think the >>> communication >>> 'standard' could and should be simpler as outlined above >>> >>> Regards >>> >>> Mike Mair >>> NZHUG \(NZ HL7 User Group\) >>> >>> Sent: Wednesday, June 05, 2002 12:17 PM >>> Subject: Re: The concept of contribution >>> >>>> \[Forwarded response from Sam Heard\] >>>> >>>> Thomas Beale wrote: >>>> >>>>> In the current issue \(3\.11\) of the EHR reference model, we have >>>>> documented the concept "contribution" as being that collection of >>>>> TRANSACTIONs corresponding to a single clinical session\. That is to >>>>> say, due to a patient contact, there could be the following new >>>>> TRANSACTIONs: >>>>> >>>>> \- patient contact \(this causes a new VERSIONED\_TRANSACTION\) >>>>> \- update to family history transaction \(new version in existing >>>>> VERSIONED\_TRANSACTION\) >>>>> \- update to current medications \(new version in existing >>>>> VERSIONED\_TRANSACTION\) >>>>> \- update to plan \(new version in existing VERSIONED\_TRANSACTION\) >>>>> \- etc >>>>> >>>>> So the contribution in this case would be four TRANSACTIONs, each in >>>>> distinct VERSIONED\_TRANSACTIONs, and each having identical details > > in >>>>> the CLINICAL\_CONTEXT object\. >>>>> >>>>> Now\.\.\. contributions are the unit of change of the record\. The >>>>> question is, do we need to be able to easily find them after the > > fact, >>>>> or is it not really important\. If it is not important most of the >>>>> time, then we can do nothing, sicne they will in fact be findable by >>>>> looking for those TRANSACTIONs which have the right CLINICAL\_CONTEXT >>>>> objects\. However, this will be slow, as it means going through all >>>>> transactions in the entire record\. If it is important to be able > > find >>>>> contributions quickly \(as I have theorised in the past, and Andrew >>>>> Goodchild at the DSTC suggests\), then we need to formalise the > > concept >>>> >>>> I do not think that we do but I am happy to hear what people >>> >>> have to say\. >>> I >>>> think it is the same function as putting the date back \- ie a > > historical >>>> date\. In fact there is no reason why these things should all be >>> >>> changed at >>>> once \- a computer might be left on for an hour and then the rest is >>>> committed \- what is that? >>>> >>>>> Andrew has also suggested that EHR extracts are really a kind of >>>>> "contribution", since they are effectively a bag of TRANSACTIONs to > > be >>>>> applied to en EHR\. While the TRANSACTIONs in the EHR\_EXTRACT are not >>>>> due to the same clinical session \(they could be anything, depending > > on >>>>> what the requestor asked for\), their addition to the receiving EHR >>>>> will in fact be a contribution\. >>>> >>>> This is a merge\_audit and I do not think that they have the >>> >>> same status in >>>> any way\. >>>> >>>>> If we are to formalise this concept, we need to have use cases > > showing >>>>> when/why contributions need to be handled as explicit entities\. >>>>> >>>>> If we can prove the need, the following architectural possibilities >>>>> suggest themselves: >>>>> \- use FOLDERs to act as contributions, i\.e\. every time a > > contribution >>>>> goes in, make a new FOLDER that contains the references to those >>>>> TRANSACTIONs >>>>> \- define CONTRIBUTION as a new subtype of FOLDER and use it as above >>>>> \- if we consider a contribution to be the equivalent of an outer >>>>> transaction in a nested transaction, then we might create a new >>>>> TRANSACTION for each controbution, whose contents are links to the >>>>> other transactions in the contribution, >>>>> \- we could always add links to the first TRANSACTION in a > > contribution >>>>> pointing to the other TRANSACTIONs in the group\. >>>>> >>>>> thoughts? >>>>> >>>> NO way Jose \- can I be any stronger than that? >>>> >>>> \- Sam >>>> >>>> \- >>>> If you have any questions about using this list, >>>> please send a message to d\.lloyd@openehr\.org >>>> >>> \- >>> If you have any questions about using this list, >>> please send a message to d\.lloyd@openehr\.org >>> >> \- >> If you have any questions about using this list, >> please send a message to d\.lloyd@openehr\.org >> > \- > If you have any questions about using this list, > please send a message to d\.lloyd@openehr\.org \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #19 by @Tim_Benson > From: Gerard Freriks <gfrer@luna\.nl> > Date: Sat, 08 Jun 2002 17:54:55 \+0200 <snip> > CEN started to standardise message components\. Lego bricks\. </snip> The issue of standardised components raises very interesting issues\. There are three different types of reusable element that we need to consider: 1\. Reusable Business Patterns\. These are sub\-function type requirements specifications, including use case and business information model, written in a way to encourage re\-use in requirements specifications\. 2\. Reusable Design Components\. These are reusable chunks of design specification \(using a common architecture\) which can be reused\. CEN GPICs and HL7 V3 CMETs seem to both fall into this category \(and need to be brought together\)\. 3\. Reusable Technology Components\. These are reusable chunks of technology\-specific implementable specification\. A good example is provided by XML complex types within a referenced name space, which have been developed specifically for reuse\. There is a clear relationship between these three types of reusable element, but there is not a strict one to one mapping across them\. They are not all different aspects of the same Lego brick\. They each are used by different people to do different things\. There may be a relationship between them, but that is not necessary to achieve the major benefits of reusability\. When someone offers me a Lego brick, I want to be quite clear whether it is a reusable business pattern, a design component or a technology component\. The predicted market for software components failed to grow as forecast during the 1990s simply because the software components were just offered as technology components \(have widget, just pay me and then use it for whatever you like\), and not anchored in a common design architecture that dealt with semantics properly, nor on business patterns\. If standards \(including standards for reusable elements\) are properly anchored in specific use cases, then we can rid ourselves of a great deal of the bloated optionality which is the curse of so many otherwise good standards\. Tim --- ## Post #20 by @Tim_Benson Ed, I agree entirely with what you say\. I keep being reminded of the excellent ISO definition of Consensus: Consensus is general agreement, characterized by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process which involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments\. Tim --- ## Post #21 by @system Ed, The invitation by the HL7 board is received well\. We will try to make it to Baltimore\. Harmonisation between CEN and HL7 is and stays our long term goal\. CEN achieved a lot towards this goal in project teams 41 and 42 working on GPICS harmonised with HL7 and a set of Lab related messages based on GPICS\. The next phase of interactions between CEN and HL7 will have to be discussed\. Templates, Archetypes, GPICS, Archetype methods, Datatypes, the EHR will be topics of interest for all of us\. Plus the way in which we both can have a process of harmonisation that is effective pragmatic and reciprocal, might be an other important topic\. Gerard Ps: I'm giving you my personal thoughts\. > It is difficult for me to stay on the sidelines\. HL7 recognizes the value > of CEN and GEHR to its work\. HL7, for example, has invited the chair of > CEN and the convenors of the work groups to the next meeting\. What I think > we need to declare is what is real and what is pretend in working together > \- on both sides\. I declare and I believe that HL7 is interested in both > groups\. What that means is not that we \(or I\) will drop what I am doing > and accept something different\. What it means that I am willing to dialog > and debate the issues\. I firmly believe that all groups will be mush better > off if we discuss and deal with our differences rather than each go our > different ways\. We need to find a way for all groups to move ahead > together and still do what we each have to do to stay alive and even grow\. > My belief is that V3 will become stable much more quickly than Gerard > implies\. I agree that CDA needs to move ahead with CDA level 3\. I am also > curious as to what clinical templates will do to level 3\. I certainly hope > we can get together on architypes, GPICS, clinical templates, and Huffs/3M > clinical data models\. > > What say? > > Ed Hammond > By the way, these are my opiniuons\. I'm not sure anyone else wants them\. > > Ed > \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #22 by @William_E_Hammond Gerard,       I like your personal thoughts\., I am very excited abouyt the possibilities of archetypes, GPICS, archetypes and such\.\. Tom Marley proposed a merger of concepts into what he calls CHICS\. While politically incorrect, I like the possibilities\. Thanks for the remarks\. Ed --- ## Post #23 by @thomas.beale Mike Mair wrote: > Why not just limit the 'standard' to dictionaries of archetypes \(informed by > ontologies\), and containers to convey them\. > what we're doing is not much more than that\. The containers are transactions or CEN compositions; to move them elswhere, wrap them in an EHR\_EXTRACT\. > We can use the access control > and document navigaton features of the CDA to convey the clinical objects > harvested at the health event\. The level 2\-3 CDA is a hybrid, part document, > part container\. A Health Event Summary, a Transaction, a EHR Extract, and > a CDA document have very similar properties, including 'Persistence, > Stewardship, Wholeness, and human readiablity' \(from the CDA specs\)\. > Standards work is about achieving a shared way of doing something, so if we > all just adopt this 'low hanging fruit' the 'standard' will be served\. > > There's work enough to do to get a shared design for the clinical objects\. > Thomas Beale suggests that the CDA might have a role integrating legacy > systems into his EHR, which might be fine if the rest of us are 'legacy'\. We > can use the CDA for our baseline interoperability between all systems > including GEHR systems\. > I'll just expand on what I meant \- I meant "legacy" systems which represent their data primarily as narrative \- unstructured text, not as structured data\. This is where the CDA comes in because level 1 or level 2 will handle the various levels of structuring\. > I am still not convinced that it is an EHR structure that has to be shared > for meaningful communication\. Both aspects of interoperabiliy, functional > and semantic, can be served without sharing an EHR structure\. > Ah but they cannot \- if you can't write software which can assume the structures of data, you cannot do anything at all\. \- thomas beale --- ## Post #24 by @Mike_Mair Dear Gerhard, You said: > Why the focus on HL7 only? CEN/TC251 has started work on the EN 13606 and is precisely what you want\. HL7 version 3 and >CDA will be to unstable for some time to come\. HL7 doesn't adopt the GEHR \(CEN\) two model approach\. > Artifacts based on the present HL7 version 3 RIM will prove to be unimplementable as a system or object\. We can be very encouraged that you may get together with HL7 on this\. However you \(or was it Gunnar Klein\) did say in your ?Berlin CEN meeting 2002 presentation \(the presentation has disappeared from the www\.openehr\.org\. site\) that EN 13606 had limited uptake because it was: a\) incomplete or have offered only partial coverage of the healthcare domain; b\) unnecessarily complex; c\) too generic, leaving the various implementations too much variability in how the models are applied to a given domain; d\) flawed, with some classes and attributes not implementable as published; e\) requiring expensive re\-engineering of systems; f\) containing features not required by the purchasers of clinical systems\. The time is evidently ripe for a synthesis\. I agree about the importance of narrative: You said: > It is a narrative for personal usage\. > When information is to be shared the author will select and rewrite parts > of his notes in order to meet a specific request by an other healthcare provider\. > This is the way people work\. This is the way healthcare providers know how > to work with using paper systems\. Perhaps the record is a resource to make stories out of? The original 'syntagm' is just the first, and even that was an interpretation\.The 'true' story is unknowable\. > I can see that objective information \(orders, test results\) can be shared by > all without real problems\. But people \(good healthcare\) will need subjective > narrative as recorded in their personal Medical Records\. Free text remains indispensable, structured data is just the debris left behind \- it's a point of view\.\.\. Regards Mike Mair --- ## Post #25 by @system Mike, I don't remember what was in the Berlin presentation by Gunnar, I think\. It is a fair list of reasons why the uptake is slow\. But what can one expect within a few years? It took more than 6 years before a CEN standard on ECG\-signals was used all over the world\. What is used of HL7 version 2\.2 or 2\.3, I expect\. And both CEN and HL7 have a lot of optionalities, since the approach is generic\. The re\-engineering of systems is the case with standards used in implementations in systems\. And the EHR standard could be implemented in systems it is not only a messaging standard\. Since Berlin we learned of several European implementations of the EHR standard in systems and messages\. The implemented standard was a pre norm \(ENV 13606\) that after 3 years of use is now up for revision\. This revision will take on board the GEHR Australia en USL work via the OpenEhr proposed Models\. Talking about narrative in Medicine\. The narrative is always subjective\. It is what the narrator wants to write\. Most often it is the healthcare provider\. What he writes is not THE TRUE STORY it is the story as told by \.\.\.\. Facts are recorded, interpreted, used or ignored and placed in certain contexts\. The highly subjective recorded result is what I call the Patiënt Record\. Fact and fiction\. The EHR is the electronic version of this story based on selected re\-arranged facts\. The free text plus facts is the real stuff what medicine is about\. And the more that is stored in a structured way the better the EHR is computer processable\. Free text expressing the thoughts, the doubts, the professional expertise, are not debris at all\. Medicine is more than recorded facts and pseudo facts\. Facts? Artefacts is a better phrase\. Gerard > Dear Gerhard, > > You said: > >> Why the focus on HL7 only? CEN/TC251 has started work on the EN 13606 and > > is precisely what you want\. HL7 version 3 and >CDA will be to unstable for > some time to come\. HL7 doesn't adopt the GEHR \(CEN\) two model approach\. >> Artifacts based on the present HL7 version 3 RIM will prove to be > > unimplementable as a system or object\. > > We can be very encouraged that you may get together with HL7 on this\. > However you \(or was it Gunnar Klein\) did say in your ?Berlin CEN meeting > 2002 presentation \(the presentation has disappeared from the > www\.openehr\.org\. site\) that EN 13606 had limited uptake because it was: > > a\) incomplete or have offered only partial coverage of the healthcare > domain; > b\) unnecessarily complex; > c\) too generic, leaving the various implementations too much variability in > how the models are applied to a given domain; > d\) flawed, with some classes and attributes not implementable as published; > e\) requiring expensive re\-engineering of systems; > f\) containing features not required by the > purchasers of clinical systems\. > > The time is evidently ripe for a synthesis\. I agree about the importance of > narrative: > You said: > >> It is a narrative for personal usage\. >> When information is to be shared the author will select and rewrite parts >> of his notes in order to meet a specific request by an other healthcare > > provider\. >> This is the way people work\. This is the way healthcare providers know how >> to work with using paper systems\. > > Perhaps the record is a resource to make stories out of? The original > 'syntagm' is just the first, and even that was an interpretation\.The 'true' > story is unknowable\. > >> I can see that objective information \(orders, test results\) can be shared > > by >> all without real problems\. But people \(good healthcare\) will need > > subjective >> narrative as recorded in their personal Medical Records\. > > Free text remains indispensable, structured data is just the debris left > behind \- it's a point of view\.\.\. > > Regards > > Mike Mair > \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #26 by @aniket_Joshi Well, I wanted to refer to the clincal session, perhaps Appendicectomy surgical record was a bad example\. I am not referring to the episode but the clinical session\.I have an architecture in which a persons clinical sessions are displayed chronologically with a title describing the clinical session for example a Nuerological reference\. By giving a title to each session, the user can go the specific session and go the depth of it\. The querying model which I am refering to is; In my architecture,After the session is selected, the related records need to be found out from the transaction table and are displayed\.This is efficient because the related records are present in the intermediate table\. In case of GEHR as the structure is OOPS,the query may have to run through all the classes, which may take significant time\. I think I have expressed myself\. DR ANIKET JOSHI --- ## Post #27 by @thomas.beale Tim Benson wrote: > If standards \(including standards for reusable elements\) are properly > anchored in specific use cases, then we can rid ourselves of a great deal of > the bloated optionality which is the curse of so many otherwise good > standards\. > I agree, but they also need to be anchored in considerations from experience \(analysis patterns if you like\) and good design principles \(which do not change the requirements, but may nevertheless change the way a standard is expressed\)\. \- thomas beale --- ## Post #28 by @Dipak_Kalra Dear Mike, Whilst recovering from a heavy work schedule I'm trying to read through the openEHR mail discussion, and must apologise for not yet chipping in properly\. However, as a quickie, I must take responsibility for those reasons why there has been poor uptake of ENV 13606\. They were proposed as challenges for the new Task Force, if we wish to see the EN 13606 successor being taken up more positively by industry and by health services\. With best wishes, Dipak --- ## Post #29 by @Sam Dear All There is no doubht that the solution will have a degree of complexity \- just look at HL7 v3 which is aimed at messaging\. I believe that the HL7 and CEN EHR approaches will align \- and will include the level 3 CDA demands \- though it will take some time and must arise through implementation experience\. The time for smoked filled rooms and EHR standards is over for us at openEHR and Ocean Infomatics\. It is very helpful to have lots of ideas, but unless people are working on an implementation it is almost impossible to contribute in a major way\. I have put the challenge to CEN to have some pilot implementations of Clinical Applications to GEHR \(using our current trial implementations\) and see what the implications are of our current approach\. At least 2 European companies are interested\. I also believe that the EHR demands an information model designed specifically for that purpose \- the interoperability of EHRs\. The fantacy that sharing information based on different information models will be straight forward is evolving \- one only has to look at the difficulty of sharing a word document amongst different software \- it is often close\. The order of magnitude of complexity with health information is far greater\. So let us address the difficulties of information models, of clinical models in a two level approach and work to create an EHR that is genuinely interoperable\. It will take resources \- but to have it working as a sharable component will take 0\.1% of about 3 countries health IT development budget and 10 good minds\. I think it is really starting to happen\! Cheers, Sam --- ## Post #30 by @Denis_Nosworthy Sam, Well said\. We have for many years been operating under the ideas of 'interoperability' and whilst tools such as HL\-7 have been very successful in getting us through these times the issue of EHR interoperability will be something else yet again\. Source system interoperability is one thing however \(mostly constrained within a controlled environment\) but receiving systems such as EHRs will have to be truly interoperable if they are to be effective\. The EHR is not a messaging system as some would have us believe \(in some incantations it could be seen to be just that\) but it must be a system that clinicians can rely on to be accurate and reflect 'real life'\. If it has to rely heavily on 'real time' messaging then the vagaries of our telecommunications systems will have a significant impact on that level of acceptance [details="(attachments)"] [InterScan\_Disclaimer.txt|attachment](upload://l69U5acbdcV3RS22BlooW11q9F6.txt) (622 Bytes) [/details] --- ## Post #31 by @Li_Henry Hi I am not a real techno but I understand and deeply interested in the discussion\. I had this vision of a real good electronic health record\. It is one own by the patient, carry by the patient, and presented to the health care provider \(whoever they are\) by the patient \(all over the world\)\. The Browser and XML or its improved version whatever it may be in the future is the way to go\. This is the process A patient visits a care provider and presents his e\-card as a proof of consent to treatment The health care provider loads up the health record into the browser and download the info into whatever system he is using \(this applies to Hospital as well\), the health care provider can also choose to discuss the patient with other health profession on line through the web\. When the patient leave the care provider, it is the responsibility of the care provider to upload whatever he has done to the patient back to the e\-card and the patient goes away\. Any subsequent test results etc, it is the responsibility of the health care provider to contact the patient to have the data put into the patient's e\-card\. \(the patient can choose not to do so \- but it is of course to the patients benefit to do so\) The benefit of this is at any one time, the patient is the only person that has a complete health history of himself and he owns it\. \(Solve the ownership and privacy issue\) After all, currently, the health care provider will only know as much as what the patient choose to tell them anyway\. New industry will start up to take care of the situation and provide all sorts of support to the e\-card holders\. These services include how to download, how to backup or even help retrieve data in emergency etc\. etc\. \- god knows what will come up in the commercial world\. Good or bad, no big brothers\. When the patient dies, he can choose to sell his e\-card for research purposes and has money to bury himself \- no burden to next of kin\. The reason I write these is that, I think I contribute as from a dumb user's point of view, may be it has some bearing on the design and the structure of the 'database' or 'rules' or whatever you may call it\. The only consideration will be where to put different types of health data in the structure\. It is upto the provider system to come up with the download and upload method\. Cheers Henry Li --- ## Post #32 by @Liora_Alschuler Sam, I agree that a certain degree of convegence is desirable and inevitable and will evolve over time based on implementation experience, but what is the reference to smoke filled rooms about? Liora --- ## Post #33 by @Mike_Mair Dear Thomas > >I am still not convinced that it is an EHR structure that has to be shared > >for meaningful communication\. Both aspects of interoperabiliy, functional > >and semantic, can be served without sharing an EHR structure\. > > > Ah but they cannot \- if you can't write software which can assume the > structures of data, you cannot do anything at all\. Popper would be proud of you \- that's falsfiable\. The structures of data and those of EHR need not be the same \(there's the rub\) Regards Mike Mair --- ## Post #34 by @thomas.beale Mike Mair wrote: > Dear Thomas > >>> I am still not convinced that it is an EHR structure that has to be >>> > > shared > >>> for meaningful communication\. Both aspects of interoperabiliy, functional >>> and semantic, can be served without sharing an EHR structure\. >>> >> >> Ah but they cannot \- if you can't write software which can assume the >> structures of data, you cannot do anything at all\. >> > Popper would be proud of you \- that's falsfiable\. The structures of data and > those of EHR need not be the same \(there's the rub\) > we are at cross\-purposes with our terms \- the whole raison d'etre of the openEHR EHR model is to state the semantics of shareable EHRs\. How anyone implements their own EHR system is their business, and the standard says nothing about that\. Clearly all software written to the shareable EHR standard has to understand what it is in order to be able to do anything\.\. \- thomas --- ## Post #35 by @Sam Henry Thanks for the 'dumb' contribution\. I hope that you can see that openEHR has approached the problem in a way that will allow the sort of scenarion that you have painted as well as a more complex scenario with a distributed record \- or even the big brother one record for each patient held centrally\. The reason is that we cannot predict the size of future work units or the technology that will be around \- only that the technology should not dictate the work practices \- only support them\. Cheers, Sam --- ## Post #36 by @thomas.beale Li, Henry wrote: > This is the process > A patient visits a care provider and presents his e\-card as a proof of > consent to treatment > > The health care provider loads up the health record into the browser and > download the info into whatever system he is using \(this applies to Hospital > as well\), the health care provider can also choose to discuss the patient > with other health profession on line through the web\. > > When the patient leave the care provider, it is the responsibility of the > care provider to upload whatever he has done to the patient back to the > e\-card and the patient goes away\. Any subsequent test results etc, it is the > responsibility of the health care provider to contact the patient to have > the data put into the patient's e\-card\. \(the patient can choose not to do so > \- but it is of course to the patients benefit to do so\) > So now there are copies of the EHR a\) on the patient's card, and b\) on the system\. Over time there will be many copies of the EHR, some more up to date than the copy on the patient's card\. What's the point of having a copy of the EHR on the patient's card? > The benefit of this is at any one time, the patient is the only person that > has a complete health history of himself and he owns it\. \(Solve the > This won't be true \- over time I doubt that anyone will have a complete history of the patient \- they will all have partial histories, which admittedly is the curret situation, but I don't see any utility in having yet another copy of part of the EHR on the card\. Re: the fear of big brother \- I agree this is real; but the solutions in my opinion lie in: \- distributed computing systems \- data management by clinical and/or public bodies \(non profit enterprises in other words\) \- strict governance of information and enforcement of consent \- data ownership by the patient \- thomas beale --- ## Post #37 by @Tony_Grivell > Li, Henry wrote: > >> This is the process >> A patient visits a care provider and presents his e\-card as a proof of >> consent to treatment >> >> The health care provider loads up the health record into the browser and >> download the info into whatever system he is using \(this applies to Hospital >> as well\), the health care provider can also choose to discuss the patient >> with other health profession on line through the web\. >> >> When the patient leave the care provider, it is the responsibility of the >> care provider to upload whatever he has done to the patient back to the >> e\-card and the patient goes away\. Any subsequent test results etc, it is the >> responsibility of the health care provider to contact the patient to have >> the data put into the patient's e\-card\. \(the patient can choose not to do so >> \- but it is of course to the patients benefit to do so\) >> > > So now there are copies of the EHR a\) on the patient's card, and b\) on the system\. Over time there will be many copies of the EHR, some more up to date than the copy on the patient's card\. What's the point of having a copy of the EHR on the patient's card? > >> The benefit of this is at any one time, the patient is the only person that >> has a complete health history of himself and he owns it\. \(Solve the >> > > This won't be true \- over time I doubt that anyone will have a complete history of the patient \- they will all have partial histories, which admittedly is the curret situation, but I don't see any utility in having yet another copy of part of the EHR on the card\. > > Re: the fear of big brother \- I agree this is real; but the solutions in my opinion lie in: > > \- distributed computing systems > \- data management by clinical and/or public bodies \(non profit enterprises in other words\) > \- strict governance of information and enforcement of consent > \- data ownership by the patient > > \- thomas beale One attractive option that goes some way to satisfy the above ideals is to have any particular data exist in only one primary location \(backed up, of course\), and therefore the total record "scattered" potentially around the world\. The patient\-held e\-card \(also backed up somewhere?\) carries the \_index\_ to these locations/data, as well as being the physical part of a "key" that allows access to this data, and maybe also carrying some portion of the data \(at least a summary of key events and critical information such as serious allergies, medication etc\) tony grivell --- ## Post #38 by @system Hi, After analysis done by the Smartcard people in the Netherlands they came to the conclusion that Smartcards with significant medical information on it need special safety procedures and back\-up facilities\. These extra's necessitate a full back\-up centrally and create synchronisation problems\. Everything is technically feasable\. But was to expensive\. They concluded: the smartcard must be used in the process of identification, only\. And even that was very expensive\. With regards, Gerard >> Li, Henry wrote: >> >>> This is the process >>> A patient visits a care provider and presents his e\-card as a proof of >>> consent to treatment >>> >>> The health care provider loads up the health record into the browser and >>> download the info into whatever system he is using \(this applies to Hospital >>> as well\), the health care provider can also choose to discuss the patient >>> with other health profession on line through the web\. >>> >>> When the patient leave the care provider, it is the responsibility of the >>> care provider to upload whatever he has done to the patient back to the >>> e\-card and the patient goes away\. Any subsequent test results etc, it is the >>> responsibility of the health care provider to contact the patient to have >>> the data put into the patient's e\-card\. \(the patient can choose not to do so >>> \- but it is of course to the patients benefit to do so\) >>> >> >> So now there are copies of the EHR a\) on the patient's card, and b\) >> on the system\. Over time there will be many copies of the EHR, some >> more up to date than the copy on the patient's card\. What's the >> point of having a copy of the EHR on the patient's card? >> >>> The benefit of this is at any one time, the patient is the only person that >>> has a complete health history of himself and he owns it\. \(Solve the >>> >> >> This won't be true \- over time I doubt that anyone will have a >> complete history of the patient \- they will all have partial >> histories, which admittedly is the curret situation, but I don't see >> any utility in having yet another copy of part of the EHR on the >> card\. >> >> Re: the fear of big brother \- I agree this is real; but the >> solutions in my opinion lie in: >> >> \- distributed computing systems >> \- data management by clinical and/or public bodies \(non profit >> enterprises in other words\) >> \- strict governance of information and enforcement of consent >> \- data ownership by the patient >> >> \- thomas beale > > One attractive option that goes some way to satisfy the above ideals > is to have any particular data exist in only one primary location > \(backed up, of course\), and therefore the total record "scattered" > potentially around the world\. The patient\-held e\-card \(also backed > up somewhere?\) carries the \_index\_ to these locations/data, as well > as being the physical part of a "key" that allows access to this > data, and maybe also carrying some portion of the data \(at least a > summary of key events and critical information such as serious > allergies, medication etc\) > > tony grivell > >> \- >> If you have any questions about using this list, >> please send a message to d\.lloyd@openehr\.org \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #39 by @system > > Li, Henry wrote: > >> This is the process >> A patient visits a care provider and presents his e\-card as a proof of >> consent to treatment >> >> The health care provider loads up the health record into the browser and >> download the info into whatever system he is using \(this applies to Hospital >> as well\), the health care provider can also choose to discuss the patient >> with other health profession on line through the web\. >> >> When the patient leave the care provider, it is the responsibility of the >> care provider to upload whatever he has done to the patient back to the >> e\-card and the patient goes away\. Any subsequent test results etc, it is the >> responsibility of the health care provider to contact the patient to have >> the data put into the patient's e\-card\. \(the patient can choose not to do so >> \- but it is of course to the patients benefit to do so\) >> > > So now there are copies of the EHR a\) on the patient's card, and b\) on > the system\. Over time there will be many copies of the EHR, some more up > to date than the copy on the patient's card\. What's the point of having > a copy of the EHR on the patient's card? > >>>>>> This is the position of the Dutch Smartcard Group\. >> The benefit of this is at any one time, the patient is the only person that >> has a complete health history of himself and he owns it\. \(Solve the >> > > This won't be true \- over time I doubt that anyone will have a complete > history of the patient \- they will all have partial histories, which > admittedly is the curret situation, but I don't see any utility in > having yet another copy of part of the EHR on the card\. > > Re: the fear of big brother \- I agree this is real; but the solutions in > my opinion lie in: > > \- distributed computing systems > \- data management by clinical and/or public bodies \(non profit > enterprises in other words\) > \- strict governance of information and enforcement of consent > \- data ownership by the patient >>>>>>> Agreed\. But \.\.\. "data ownership by the patiënt" will need some consideration\. I know that most laws in most countries are politically correct and give rights to patients\. But never ownership\. Most often a right to inspect, review, remove, and add information\. In my way of thinking, the author is the owner and one responsible\. The patiënt has the right to see his information and under certain conditions is able to remove it or change it\. But what is "Information"? I think that there are levels or types of information: "Private Opinions" consisting of personal interpretations of raw data; "Official Statements/opinions" consisting of professional interpretations of raw data; "Raw uninterpreted data" admitted to the EHR; "Raw interpreted data" not admitted to the EHR, \(yet\) Patiënt have rights towards the last two, but none with the first\. Healthcare providers must have the facility record private unripe thoughts about the patiënt and its disease process\. The author os the information is acting as the proxy of the patiënt\. Patients should have no direct access to all the information\. Only to selected portions of the " Official opinions"\. The preferred way to inspect and change is via the responsible proxy\. > \- thomas beale > > \- > If you have any questions about using this list, > please send a message to d\.lloyd@openehr\.org \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #40 by @thomas.beale Tony Grivell wrote: > One attractive option that goes some way to satisfy the above ideals is to have any particular data exist in only one primary location \(backed up, of course\), and therefore the total record "scattered" potentially around the world\. The patient\-held e\-card \(also backed up somewhere?\) carries the \_index\_ to these locations/data, as well as being the physical part of a "key" that allows access to this data, and maybe also carrying some portion of the data \(at least a summary of key events and critical information such as serious allergies, medication etc\) whether it could even carry a reliable index of these locations is doubtful in my mind \- people are too forgetful, they won't usually make the effort\. But the critical information should of course be there\. Most critical info is fairly non\-volatile and does not need to be updated that often \(current medications the probable exception\)\. \- thomas --- ## Post #41 by @David_Guest Hi Gerard I have been sitting here in the OpenEHR since February and all of sudden last month someone put through a cyberhighway and the din from traffic has increased enormously\. For those who have transferred from other lists I apologise if my ponderings are too facile or have already been covered ad nauseam\. I have never understood the concept of data ownership\. I can understand the ownership of things, like hard drives and CD\-ROMs, but not data\. Data seems to me like a mathematical algorithm or poetry\. You can create it, you can interpret it and you can store it\. You can also send it on to someone else and these days the electronic copy you send is the same as the original\. Medical data is collected from patients by health care professionals\. Each of them has specified read / write permissions but, at least in Australia, not deletion rights\. If you introduce third parties \(HMOs, governments, employers\) you also need to define their rights\. Having worked under the Australian "open system" since a change to the Privacy Act six months ago, I find that there are hardly any times when you need to withhold information from the patient\. I cannot see the point in restricting access to "private" opinions\. My letters of referral, which the patient can read in full, contain a copy of my clinic notes\. The consultant pyschiatrist soon fathoms out my diagnosis of "voices for investigation" and the patient is painfully aware of the symptom\. I do agree that any appendings to the record requested by the patient have to be made by the health professional\. After all, it is "your" record\. :\-\) David Gerard Freriks wrote: --- ## Post #42 by @Gunnar_Klein Dear EHR friends, I agree very much with David Guest's opinion that it less fruitful to speak about ownership of information though it is done a lot in the debate in many countries\. It is clearly different from access rights which Gerard is speaking about and like David is saying for Australia, in Sweden there is usually very little point in trying to distinguishing differnt parts of records as less relevant for the patient\. i certainly think the classification suggested by Gerard in four types of data does not hold\. Different from the access rights themselves are the rights to decide access rights which is quite complicated and varies in different situations\. In many countries today, the patient concerned always has an overriding right of deciding that "his/her" record should be released for reading to a specific person or any person\. We have an interesting debate in Sweden right now on the issue if it is possible to ask the patient to give consent to access to records not yet recorded\. Some very official legal experts claim it is not allowed according to the secrecy act to give a permission to an unknown piece of information for the future whereas other legal advisors to healthcare organisations are de facto supporting what is built in some cases where the patient gives the consent to future relaeases of information to be recorded in the future\. One example being a centralised list of all currrent medication\. For standards we have to accept that this type of serrvice will be required by some user groups whereas in other legal contexts it will not be possible\. Yet another aspect of "ownership" is the issue of destruction of the whole or parts of an EHR\. In our legislation as I believe in many others no healthcare provider has that right by itself, only a special national body, in our case the National Board of Health working directly under the ministry of Health can make a decision that allows it and in fact mandate that it shall be done usually based on a request by a patient that find that errors have been made or harmful opinions expressed by less careful professionals\. Since many EHR systems installed do not really have a function to do a removal of data, these rare situations cause special consultancy services by the EHR manufacturer often at high costs 5\-15000 EUR\. Of course a standard requirement shoudl allow for deletion but it is not a matter for EHR communication\. However, the important thing to note is that when records actually shall be deleted it shlould be all copies also sent to other providers\. Thus, the record need to store logs of record transfers and there may be a need to communicate electronically the instruction to the recieveing end to delete\. However, from a Swedish point of view these deletion issues are so rare that it is not an important requirement that this should be communicated electronically, one reason is that the instruction to another system need to convey also the proof \(a paper decision for now and a long time to come\) of the Authority decision that the record can/shall be deleted\. Best regards Gunnar Klein --- ## Post #43 by @system Gunnar, As a summary of my e\-mail: \- Ownership is irrelevant, \- Authorship is relevant, \- Authors that commit information to a record can NEVER remove the information; they can add; \- Patients can NEVER remove the information; They can add/annotate; Access control list can be changed by them, only, \- There are different types/classes of data/information, \- Each with possibly different acces control lists and rights, \- Patients need a proxy to exercise all their rights; Proxies can have mandates, \- My position isn't according to Dutch law\. It is a personal one\. Gerard > Dear EHR friends, > > I agree very much with David Guest's opinion that it less fruitful to speak > about ownership of information though it is done a lot in the debate in many > countries\. It is clearly different from access rights which Gerard is > speaking about and like David is saying for Australia, in Sweden there is > usually very little point in trying to distinguishing differnt parts of > records as less relevant for the patient\. i certainly think the > classification suggested by Gerard in four types of data does not hold\. > > Different from the access rights themselves are the rights to decide access > rights which is quite complicated and varies in different situations\. In > many countries today, the patient concerned always has an overriding right > of deciding that "his/her" record should be released for reading to a > specific person or any person\. We have an interesting debate in Sweden right > now on the issue if it is possible to ask the patient to give consent to > access to records not yet recorded\. Some very official legal experts claim > it is not allowed according to the secrecy act to give a permission to an > unknown piece of information for the future whereas other legal advisors to > healthcare organisations are de facto supporting what is built in some cases > where the patient gives the consent to future relaeases of information to be > recorded in the future\. One example being a centralised list of all currrent > medication\. For standards we have to accept that this type of serrvice will > be required by some user groups whereas in other legal contexts it will not > be possible\. > > Yet another aspect of "ownership" is the issue of destruction of the whole > or parts of an EHR\. In our legislation as I believe in many others no > healthcare provider has that right by itself, only a special national body, > in our case the National Board of Health working directly under the ministry > of Health can make a decision that allows it and in fact mandate that it > shall be done usually based on a request by a patient that find that errors > have been made or harmful opinions expressed by less careful professionals\. > Since many EHR systems installed do not really have a function to do a > removal of data, these rare situations cause special consultancy services by > the EHR manufacturer often at high costs 5\-15000 EUR\. > > Of course a standard requirement shoudl allow for deletion but it is not a > matter for EHR communication\. However, the important thing to note is that > when records actually shall be deleted it shlould be all copies also sent to > other providers\. Thus, the record need to store logs of record transfers and > there may be a need to communicate electronically the instruction to the > recieveing end to delete\. However, from a Swedish point of view these > deletion issues are so rare that it is not an important requirement that > this should be communicated electronically, one reason is that the > instruction to another system need to convey also the proof \(a paper > decision for now and a long time to come\) of the Authority decision that the > record can/shall be deleted\. > > Best regards > > Gunnar Klein > From: "David Guest" <dguest@bigfoot\.com> > To: "Gerard Freriks" <gfrer@luna\.nl> > Cc: <openehr\-technical@openehr\.org> > Sent: Wednesday, June 12, 2002 7:44 AM > Subject: Re: The concept of contribution \- first post :\-\) > >> Hi Gerard >> >> I have been sitting here in the OpenEHR since February and all of sudden >> last month someone put through a cyberhighway and the din from traffic >> has increased enormously\. For those who have transferred from other >> lists I apologise if my ponderings are too facile or have already been >> covered ad nauseam\. >> >> I have never understood the concept of data ownership\. I can understand >> the ownership of things, like hard drives and CD\-ROMs, but not data\. >> Data seems to me like a mathematical algorithm or poetry\. You can create >> it, you can interpret it and you can store it\. You can also send it on >> to someone else and these days the electronic copy you send is the same >> as the original\. >> >> Medical data is collected from patients by health care professionals\. >> Each of them has specified read / write permissions but, at least in >> Australia, not deletion rights\. If you introduce third parties \(HMOs, >> governments, employers\) you also need to define their rights\. >> >> Having worked under the Australian "open system" since a change to the >> Privacy Act six months ago, I find that there are hardly any times when >> you need to withhold information from the patient\. I cannot see the >> point in restricting access to "private" opinions\. My letters of >> referral, which the patient can read in full, contain a copy of my >> clinic notes\. The consultant pyschiatrist soon fathoms out my diagnosis >> of "voices for investigation" and the patient is painfully aware of the >> symptom\. >> >> I do agree that any appendings to the record requested by the patient >> have to be made by the health professional\. After all, it is "your" >> record\. :\-\) >> >> David >> >> Gerard Freriks wrote: >> >>> Agreed\. But \.\.\. >>> >>> "data ownership by the patiënt" will need some consideration\. >>> I know that most laws in most countries are politically correct and give >>> rights to patients\. But never ownership\. Most often a right to inspect, >>> review, remove, and add information\. >>> In my way of thinking, the author is the owner and one responsible\. The >>> patiënt has the right to see his information and under certain conditions > > is >>> able to remove it or change it\. >>> But what is "Information"? >>> I think that there are levels or types of information: >>> >>> "Private Opinions" consisting of personal interpretations of raw data; >>> "Official Statements/opinions" consisting of professional interpretations > > of >>> raw data; >>> "Raw uninterpreted data" admitted to the EHR; >>> "Raw interpreted data" not admitted to the EHR, \(yet\) >>> >>> Patiënt have rights towards the last two, but none with the first\. >>> Healthcare providers must have the facility record private unripe > > thoughts >>> about the patiënt and its disease process\. >>> The author os the information is acting as the proxy of the patiënt\. >>> Patients should have no direct access to all the information\. Only to >>> selected portions of the " Official opinions"\. The preferred way to > > inspect >>> and change is via the responsible proxy\. >>> >> \- >> If you have any questions about using this list, >> please send a message to d\.lloyd@openehr\.org > > \- > If you have any questions about using this list, > please send a message to d\.lloyd@openehr\.org \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #44 by @thomas.beale Gunnar Klein wrote: > Dear EHR friends, > > I agree very much with David Guest's opinion that it less fruitful to speak > about ownership of information though it is done a lot in the debate in many > actually, I agree \- I just used the word as shorthand for being able to exercise rights over the information, i\.e\. being the moral owner\. As a technological concept, it is not useful\. > Different from the access rights themselves are the rights to decide access > rights which is quite complicated and varies in different situations\. In > many countries today, the patient concerned always has an overriding right > of deciding that "his/her" record should be released for reading to a > specific person or any person\. We have an interesting debate in Sweden right > now on the issue if it is possible to ask the patient to give consent to > access to records not yet recorded\. > This would surely have to depend on some idea of classification of information\. You could sensibly give consent to a certain set of access rights for current medicationa and therapeutic precautions information; when more items in these categories are recorded, the patient probably does not want to have to keep restating their preferences\. But for new categories of information it should probably be different\. The trick is to devise a way of categorising health data from a user point of view\.\.\. > Yet another aspect of "ownership" is the issue of destruction of the whole > or parts of an EHR\. In our legislation as I believe in many others no > healthcare provider has that right by itself, only a special national body, > in our case the National Board of Health working directly under the ministry > of Health can make a decision that allows it and in fact mandate that it > shall be done usually based on a request by a patient that find that errors > have been made or harmful opinions expressed by less careful professionals\. > Since many EHR systems installed do not really have a function to do a > removal of data, these rare situations cause special consultancy services by > the EHR manufacturer often at high costs 5\-15000 EUR\. > now I'm smiling\. I knew there was a reason why CEN, GEHR and all the other works said you can't delete anything ;\-\) > Of course a standard requirement shoudl allow for deletion but it is not a > matter for EHR communication\. > Right; it is a system function, and a governance issue > However, the important thing to note is that > when records actually shall be deleted it shlould be all copies also sent to > other providers\. Thus, the record need to store logs of record transfers and > there may be a need to communicate electronically the instruction to the > recieveing end to delete\. > this is one way of doing it but i suspect there are better ways which have not been designed yet, due to the unknown factor of how EHRs in the future will be distributed and shared \- in community computing infrastructure? In a cerntralised infrastructure? > However, from a Swedish point of view these > deletion issues are so rare that it is not an important requirement that > this should be communicated electronically, one reason is that the > instruction to another system need to convey also the proof \(a paper > decision for now and a long time to come\) of the Authority decision that the > record can/shall be deleted\. > I suspect this should also be true for requests for prior versions of information, when only the latest is of interest to clinical care\. \- thomas beale --- ## Post #45 by @Mary_Kratz Intellectual Property Rights issues are going to loom large for the EHR, and many other aspects of how we provide clinical care, education and conduct research\. At the Internet2 Virtual Monthly Briefing yesterday Lawrence Lessig's Opening Plenary to TERNEA in Ireland was rebroadcast\. I believe the topic of a Creative Commons \(as Dr\. Lessig termed it "the NO Lawyer zone ;\-\)\) is something that is very relevant to the openEHR philosophy\. Is it time to get out of our "smoke filled rooms" and start being creative? See the links for Dr\. Lessig and the Creative Commons at http://www.internet2.edu/activities/html/20020611.html Ok, so perhaps this a very US centric viewpoint\.\.\.but still we have to start building applications at some point\. A place to share intellectual property and allow for creative thoughts to evolve through open collaboration might be a notion that we could leverage through use of the Creative Commons philosophy and resources\. \-Mary --- ## Post #46 by @David_Guest > Different from the access rights themselves are the rights to decide access > rights which is quite complicated and varies in different situations\. In > many countries today, the patient concerned always has an overriding right > of deciding that "his/her" record should be released for reading to a > specific person or any person\. We have an interesting debate in Sweden right > now on the issue if it is possible to ask the patient to give consent to > access to records not yet recorded\. Some very official legal experts claim > it is not allowed according to the secrecy act to give a permission to an > unknown piece of information for the future whereas other legal advisors to > healthcare organisations are de facto supporting what is built in some cases > where the patient gives the consent to future relaeases of information to be > recorded in the future\. One example being a centralised list of all currrent > medication\. For standards we have to accept that this type of serrvice will > be required by some user groups whereas in other legal contexts it will not > be possible\. Gunnar In Australia, the argument against agreeing to list future information is that the patient cannot be fully informed about all future scenarios\. The proposed on\-line centralised medication database, BMMS \(http://www.health.gov.au/bmms/), allows for recision of a previous agreement to participate in the scheme\. This right to opt out is presented on each occasion that you interact with the system\. > Yet another aspect of "ownership" is the issue of destruction of the whole > or parts of an EHR\. In our legislation as I believe in many others no > healthcare provider has that right by itself, only a special national body, > in our case the National Board of Health working directly under the ministry > of Health can make a decision that allows it and in fact mandate that it > shall be done usually based on a request by a patient that find that errors > have been made or harmful opinions expressed by less careful professionals\. > Since many EHR systems installed do not really have a function to do a > removal of data, these rare situations cause special consultancy services by > the EHR manufacturer often at high costs 5\-15000 EUR\. > > Of course a standard requirement shoudl allow for deletion but it is not a > matter for EHR communication\. However, the important thing to note is that > when records actually shall be deleted it shlould be all copies also sent to > other providers\. Thus, the record need to store logs of record transfers and > there may be a need to communicate electronically the instruction to the > recieveing end to delete\. However, from a Swedish point of view these > deletion issues are so rare that it is not an important requirement that > this should be communicated electronically, one reason is that the > instruction to another system need to convey also the proof \(a paper > decision for now and a long time to come\) of the Authority decision that the > record can/shall be deleted\. I cannot see how this will work in practice\. The data has been burned to a hundred CDs at the clinic and possibly to a similar number at my colleagues' surgeries\. Deleting the information will also cause a mismatch in the hash between that of the modified database and those that have already been filed on the gnotary servers \(http://www.gnumed.net/gnotary/). Perhaps what you are really trying to achieve is removal of access rights by everyone\. You still cannot rewrite history, however\. David --- **Canonical:** https://discourse.openehr.org/t/the-concept-of-contribution/14441 **Original content:** https://discourse.openehr.org/t/the-concept-of-contribution/14441