Subject of care
Hi, S.o.C can mean many things: One person One mother or foetus Any body part in or outside the body And any grouping of items mentioned above. A S.o.C indicates the participation in activities. Gerard On 2002-12-01 23:38, Sam Heard sam.heard at bigpond.com wrote: Dear all I have been reviewing the subject of care - over family history. It is clear that the following information is potentially useful: 1. The name of the person so you can refer to them as so-and-so 2. The relationship (father, mother) this might or might not include their genetic relationship (adoptive) - at present I have this in the genetic relationship boolean value of the family history problem. I think this is the most appropriate as it is the only time when it is essential to know it?? 3. The ID of the person in the demographic server - allowing contact details etc. Can others think of other issues with identifying the subject of an entry in the EHR - (not the ehr itself!) Times when this is likely are around the birth of a child and for family history problems. Cheers, Sam Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Model CEN/TC251 13606
Dear Mike, What sets aside a document from a message? What is recorded in q EHR system? A document is the information a healthcare provider attests by signing it. It contains a set of information in a clear context. What is submitted in a EHR system has to be a set of documents, in my view. Next to the set of documents other information is part of the record: lab tests, etc. In my view documents are persistent and reflect those parts of the recorded and exchanged information that the healthcare provider attested. Documents are not virtual at all and always exist. Gerard On 2002-12-04 14:00, Mike Mair mikemair at es.co.nz wrote: Dear Gerard, David One definition of the GEHR 'kernel' is that of 'record engine'. I wondered what your view of the CDA was now in this role, after the Berlin CDA conference? The succession of CDAs can be turned out by any suitably equipped record system, and the CDAs used as a common currency for them. Sometimes these CDAs might not actually exist unless created for their communicative role between systems, in which case they are virtual CDAs, and the record engine entirely 'virtual'. This substitutes a 'virtual kernel' for the GEHR product, and does the same job of providing a communality of process between participant record systems without the specifics of the GEHR kernel, but it still would permit use of GEHR type components such as archetypes. Regards Mike Mair - Original Message - From: David Lloyd d.lloyd at chime.ucl.ac.uk To: openehr-technical at openehr.org Sent: Tuesday, December 03, 2002 8:40 PM Subject: Re: Model CEN/TC251 13606 Gerard Several points: 1.Specifically, openEHR proposes a number of Reference Models, supplemented by Archetype Models. 2. You seem to use the word 'Kernel' as a synonym for Reference Model. If this is not so, please will you explain your use of the word Kernel? 3. The Reference Models proposed by openEHR are just sufficient to meet the set of published requirements (e.g. ISO 18308) for an EHR and apply to _any_ EHR. It is necessary to delineate various levels in the Architecture in order to be able to place Classes, Attributes, and Functions appropriately to meet the requirements. 4. The Reference Models are indeed generic, in the usual sense that they are not prescriptive about what _information_ must be in an EHR, but make possible the representation of all those kinds of information known to exist in (or be necessary for future) EHRs. 5. For each Reference Model there will be a corresponding Archetype Model (only the Data Types Archetype model has so far been released). Authors of actual Archetypes, conforming to the Archetype models, will be able to impose the required constraints of their domains to guide the construction of instances of EHRs. 6. To my way of thinking, everything about the Reference Models is _generic_. Archetypes provide the means of using the models to construct EHRs for particular, i.e. non-generic, domains. I hope this helps to resolve what appears to be a fundamental difference between us! With best wishes David At 21:02 02/12/2002 +0100, you wrote: Dear colleagues, The last week I had a discussion with some colleagues of me at TNO. They studied the OpenEhr proposal for a model for the EHR. It is their opinion, and I agree with it, that the Kernel is not generic enough because it contains things like the structure of the document (folder, transaction, etc) Even things like an organiser archetype must become a real archetype and be not a part of the kernel. With regards, Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org * David S.L. Lloyd, Technical Consultant * CHIME - Centre for Health Informatics and Multiprofessional Education, at UCL * E-Mail: d.lloyd at chime.ucl.ac.uk Tel: +44 (0)20 7288 3364 * Web: www.chime.ucl.ac.uk/~rmhidsl#contact - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Terminology services
Thomas, I disagree. I disagree because in essence both are the same. It is in the richness versus reduced richness that there is a difference. And that difference is not major. As a physician I believe in free text and narrative. Healthcare is exchange of information between responsible humans in the first place and secondly between databases. And free text in a rich narrative structure is the way in which humans can express them selves in a rich way as complete and accurate as they can. The richer the structure of the free text or narrative the better the information can be expressed in a structured way. The richer the text is structured using concepts from a source the better information can be expressed in an analysable form. A rich ontology is better than a restricted code set. Gerard On 2002-12-18 17:01, Thomas Beale thomas at deepthought.com.au wrote: Philippe AMELINE wrote: Hi, Since I missed the starting point of this thread, I may un-properly answer ; however I can say from the work we are doing that there is a great difference between a system based on an ontology and a system based on free text annotated by a coding system. The fist one allows structured description (knowledge management field) while the other remains in the field of classification (data management : text index keeping and epidemiology). And I have to agree 100%. But I doubt if Gerard really disagrees with this. - thomas - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
The concept of contribution
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 On 2002-06-12 04:18, Tony Grivell tony.grivell at flinders.edu.au wrote: At 11:34 +1000 12/6/02, Thomas Beale wrote: 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 at openehr.org -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
The concept of contribution
On 2002-06-12 03:34, Thomas Beale thomas at deepthought.com.au wrote: 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 at openehr.org -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Re Ownership
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 On 2002-06-12 10:58, Gunnar Klein gunnar at klein.se 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 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 - Original Message - From: David Guest dguest at bigfoot.com To: Gerard Freriks gfrer at luna.nl Cc: openehr-technical at 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
Archetype ontology
Sam, Could the following be another example? The Blood pressure. The RR as an act, a measurement, a procedure. And the RR as a set of values, the result of the act, the measurement results, the result of a procedure. The act is one thing, an intention. The value as the result of the execution of the intention. The intention can exist without a real value. In ENV 13606 part 2 there are the possibilities to add modifiers (attributes) to 'things' that can express concepts like these. The question is: Will we need a new Concept Information Model (archetype) to distinguish between the two or is one attribute enough? Gerard On 03-09-2002 22:31, Sam Heard sam.heard at bigpond.com wrote: Dear all, I have been working hard to get an ontology of archetypes developed that will show the health domain mapped into the openEHR architecture. I have found a couple of things: 1. That there is often a link between an instruction and subsequent observations - which I think will be more important as knowledge bases are developed in the future. I have called the link an action specification and at present it is modelled as part of the instruction. Let me give a real example. If you prescribe a medicine then there are a number of attributes of that medication order - dose, form, route etc - and there is the frequency of administration. When you record that a medication has been administered - then you record the dose, form, route etc - but not the frequency. The link is the specification of the action - but not the conditional elements of the instruction. Many other things may be specified at the time that they are ordered and there may be protocols etc that are to be followed. For this reason - I have two new subclasses in the ontology (not in openEHR) - openEHR Observation - action and openEHR action specification. This allows me to say which action specification applies to an instruction and which obeservations it applies to. 2. It might be necessary to state the sequence of different instructions. The French oncologists wish to state this for Surgery, Radiotherapy, Chemotherapy etc. Clearly each of these will have a complex action specification. How then to make it clear about the order of the instructions - should one finish before the other starts? I welcome your ideas. I have put the zipped (45K) protege files on www.gehr.org in the Watch this space section. Cheers, Sam Dr Sam Heard The Good Electronic Health Record Ocean Informatics, openEHR 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.gehr.org www.openEHR.org __ - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype ontology
On 13-09-2002 16:51, Melvin Reynolds MelvinR at AMS-Consulting.co.uk wrote: However, the final statement ... As soon as one starts thinking about what has to happen to turn messages into EHR content, it becomes clearer and clearer that the EHR is nothing like a compendium of messages; for from it - it is a time-based accumulator of EHR information, some of which is sourced from messages, much of which is created by human users of GUI applications. seems like a gross oversimplification of the reality. It is true a readable EHR is not likely to a compendium of messages. But an EHR for use in a primary care context is not likely require to present the same information (in full) as an acute secondary care EHR; and neither are likely to require to present the full audit trail of all messages, requests and reports that would be required of a medico-legally complete (but clinically unhelpful) EHR. The information a healthcare provider submits to the record is what he/she sees on the screen. This committed information has to be signed. It is not sufficient that the author is recorded but for legal proof it is necessaryb that he/she signes the text with his/her private key. This is the position we (at TNO-PG) take after having studied the legal literature (1500 pages of texts from EU Directives, Dutch laws, FDA documents and ethics documents) So an EHR is a series of signed, authored messages that can be used in court. Without the fulfillment of the requirements, the EHR is nothing but information written in the sand before a wave of the sea washes it away. What an application does with the information on a screen and in its database is much less relevant from a legal perspective. What is signed is relevant. -- work -- Gerard Freriks TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype ontology
On 15-09-2002 11:26, Karsten Hilbert Karsten.Hilbert at gmx.net wrote: 1) How do I know that the passphrase I typed in to be used for the secret key is used to sign what I see on screen and nothing else ? Because a special secure device does all the encrypting. After having inserted the Health professional Card 2) How does the court know that a signed screenshot was actually shown on screen and not just fabricated and never shown ? (It is my responsibility to _inspect_ what is being shown but I cannot prove that signed screenshots were actually displayed (on current-day systems). Because the secure device is able to place the information on the screen. Having a screenshot provides a richer picture than a set of bits and bytes down deep in the database. This isn't about 100% proof, this is about level of trust, feasability, deniability and due process. Even with signing screenshots. True. I'll have more confidence in a message displayed on a screen than bits and bytes in a distributed database in an Health Information Infrastructure Or did I miss something ? Since it is my responsiblity to carefully inspect the on-screen information I could just as well extend that view to that it is my responsibility to use a system that I can trust to show me what is actually in the database. Thusly I could just as well sign database content. Gerard himself remarked that we cannot sign that anyone actually reviewed any information, only that it was made available. The latter can be at the level of a screenshot - or at the level of database content. After all it is my responsibility to inform myself no matter where I get the information from. Say, I am using an SQL shell and sign screenshots of my queries. Does this mean I am not liable for the anaphylactic reaction just because I didn't do the query for the known penicillin allergy ?!? Obviously not, although I understand your position to be: It hasn't been shown to me hence I am not to blame. What other purpose might a signed screenshot server ? To shift blame to the EHR software manufacturer ? The whole thing has to do with liability and legal proof. If next to the information in a database the style sheet used to display is stored, it is possibly good enough for legal proofs. Lastly, one simple question. How does TNO propose to handle the audit trail of signed screenshots simply in terms of storage requirements ? This is a simple problem. Now every year one hospital needs 1 kilometre of shelf space. Have you ever compressed XML documents? Have you ever looked at diskspace and prices? Making a hash of a screen dump indicates: This is the information as I saw it on a screen and take responsibility for it by signing. Nah, I doubt you really believe in the coherency of this statement. A screendump merely shows what a screen _may_ have looked like. I think it is fully coherent. Yes. But systems that have been certified will have a perfect screendump. This is something that can be tested easily. To proof that in a distributed environment all informationsystems worked 100% is much more difficult? Right? Or wrong? Gerard Karsten Hilbert -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype ontology
On 16-09-2002 03:03, Thomas Beale thomas at deepthought.com.au wrote: I think this is a good overall comment. To which I'll add that what needs to be shown to have been understood in court are simple clinical or other facts, in the form of propositions, not screen bit patterns. In court, it will nee to be shown that that clinician understood fact A, B and C before attesting the addition to the EHR. Screen shots are not the way to do this. I suggest that a standardised XML rendition of the EHR entries in question are the way to go. Also, we should be careful to differentiate between attestation - the act of the clinician agreeing that he/she has in fact seen and understood what is on the screen be fore committing it to the EHR, and signing which is an attestation that some lump of content was created by a certain person, and not someone else. I don't think signing guarantees anything about comprehension, just that a particular stream of bytes emanated from a source which is positively identified as Dr so-and-so. Slowly we are making progress. I agree that there are several reasons to sign and possibly we need ways to indicate this. I agree that there are several contexts. The lonely healthcare provider on his IT island, the one that exchanges information with a few other colleagues, the healthcare providers that are part of a complex network for the exchange of messages, the ones that are part of an higly integrated system of systems. The more complex the more detail has to be stored explicitly. I agree that 'screenshots', 'pictures' can be engineered in several ways. The most likely candidate is XML-document and XML-stylesheet. But perhaps there are others. Gerard Ps: sorry for having an extemist view. -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
openEHR Silver Model
Hi, My personal thoughts are: This discussion is trivial. CEN decided to: - renew the ENV 13606 - use the two model approach - produce a standard that can be used to produce: messages, documents and implementable objects My preference is the platinum model :-) But I go for the gold one. And as long as we can show that one is able to map to the silver one or the bronze one, I see no problem. Mapping means that we are able to produce an Archetype that fulfils the requirements of all those models. A consequence of the decision taken by CEN is that the Kernel (including the data types) plus the Archetype model must be stable and as complete as possible. The various degrees of granularity (that equals the number of concepts and equals the number of archetypes and complexity of it) will be outside of the control of the standardisation organisation. It will be in the hands of the domain experts/user communities. Each user community that wants to exchange information will use the Kernel and Archetype Model plus the set of agreed archetypes it needs to use. So we must provide all proponents of the bronze and silver options archetypes that fulfil their requirements. My option is the Patinum one ;-) Gerard Ps: A likewise argument can be made for the data type problem. We have the PT41 proposal, the HL7 one and the OpenEHR one. Possibly we have to show that all three are mappable and therefore equally correct and interchangeable. On 17-09-2002 05:48, Andrew Goodchild andrewg at dstc.edu.au wrote: Hi All, I know this is probably a very politically sensitive topic, but I am wondering what the path forward for harmonization of openEHR with CEN 13606. I was talking to Peter Schloeffel yesterday and Peter mentioned that there are three options: - the bronze option, which involved fixing a couple of things in the existing CEN model and adding archetypes to it. - the silver option, which simplifies and modifies openEHR and uses that as a basis for the new CEN model - the gold option, which uses the full openEHR model as the basis for the new CEN model Peter also mentioned to me that it was highly likely that the silver option would be the most successful. My question to the list is, what would you simplify or modify in the openEHR model? My gut feeling is to remove everything not required by ISO 18308, but I am not sure what that would entail or the side effect of that. Any thoughts? cheers, Andrew _-_|\Andrew Goodchild / * DSTC Pty Ltd \_.-._/ Brisbane, Australia vhttp://staff.dstc.edu.au/andrewg/ - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 Leiden The Netherlands +31 71 5181388 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
openEHR security
has and access control feature on ARCHETYPED in the Common Reference Model. The idea being that anything that can be archetyped - that is, it is a coherent clinical composition or concept - can have its access controlled. It is envisaged that the EHR will have an access control list which can be transfered to other centres as part of an extract if required. This requires standardisation of access control groups. We have done some work in Australia to get a set of access groups that could be standardised across health care and I enclose a copy of this document for your consideration. Hope this is a start - very interested to work with you on this! Cheers, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Bill Walton Sent: Thursday, 24 April 2003 7:36 AM To: openehr-technical at openehr.org Subject: openEHR security I apologize for not having had the time to dig in and find this out for myself yet, but I'd really appreciate it if someone could tell me if security has been addressed in the openEHR architecture and, if so, point me to the documentation. I'm trying to understand the system's capabilities to limit access not only to authorized individuals, but also to limit the access of authorized individuals to specific subsets of an individual's record. Thanks in advance for showing me where to dig. Best regards Bill -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
GEHR philosophical background info
On 2003-04-29 3:44, Thomas Clark tclark at hcsystems.com wrote: Hi Paul, You are very right concerning the involvement of judges and attorneys. The legal issues must be handled up front. -Thomas Clark Yes. The problem is that in Europe, the USA, Canada, Australia, etc, there are many legal systems. One generic solution that will fit all will be difficult. The problem is intractable because it is a problem with at 5 degrees of freedom, if not more. In order to solve this we need discussions on: Descriptions of contexts, Type of infrastructure (pull/push, federation/messaging, MAC/DAC, the level of social (persons) control versus the dependency on technology for control, etc, What is stored in the audit-log, Scenario's / use cases. And then we can have nice discussions as I read now on this list. One solution is to assume for the discussion the existence of a Service next to the EHR service that will control access. And that the EHR service is completely ignorant and passive for this Access Service to operate. Then each country (legal jurisdiction) is able to handle its own context. And we all can use the same standard for the EHR. The Access Service will act as 'firewall' and has all the responsibilities for granting access. Personally I favour this simplistic approach. But I know there are two major contexts: - within a legal entity - between legal entities. In an institution there can be a mix of these two. Within a legal entity I will depend on social measures and therefore audit trails for security. For this solution we need a set of agreed rules plus a discussion on the content of the audit-trail. Between legal entities information can only be exchanged when a person consciously accepts responsibilities for a set of information to be shared for a specific purpose with a specific set of other persons. The provisions for exceptions need to be spelled out completely. Here again the audit-tral and a set of rules are needed. But foremost it must be one person that takes full responsibility. As you can see I try to solve the problem by not depending to much on informational facilities in any EHR. But I will depend on the audit-trail where will be recorded what was published and what was accessed by whom, for what purpose, etc. This is not part of the EHR. The reason why I'm suggesting this way of solving the problem is: - the problem of access control is about handling responsibility and proof. Only persons can be held responsible - Access control easily assumes that the evaluation of Identity, Role, Participation, the trustworthiness of information (or sets if information) are constants of time. All are not constant at all over time. Therefore we can not rely on machines to operate on values judgements (rules) from the past. But we need judgements made by responsible persons as a reaction to a request by an other responsible person as much as possible. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Encoding concept-relationships in openehr archetypes.
Hi, Is it? Is it about how to represent the domain normal values? Or is it more general: Are concepts related? Then the problem is: what relations are there between concepts (archetypes)? What semantics of these relationships between archetypes (concepts) do we need to describe reallity (including decision support)? Gerard On 2003-08-04 5:38, Thomas Beale thomas at deepthought.com.au wrote: Admittedly, I'm slipping into the realm of decision support, but I think it really is simply the structure of the domain of normal values in this specific application. I'd like to use archetypes to represent this, just as a I might use them to represent the min and max of a given quantity. Is the capability all there already? If not, what's missing? -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
certification and verification of OpenEHR
Dear Chris, CEN/TC251 is co-operating with OPENEHR. We are in the process to define a next version of our EHR standard. It is basicly a standard that defines a Document and facilities for handling it properly. Plus it will enable to locate doucment items in space and time. On top of this the standard (EN136060) will include Archetypes. With these archetypes all kinds of clinical concept models can de defined by national, loca', regional organisations. Where appropiate the Archetypes will be able to use items like SNOMED-CT. And record coded information. The Archetype (=clinical concept model) The Archetypes need a stable set of archetype-fragments that define for instance the demographics of persons and organisations, but also the generic structure of a referral letter,the generic investogation, etc. We at CEN think it is a tractable problem. And the people from OPENEHR have demontrated that it is in several beta implementations. I can refer you to the OPENEHR website and the CEN one (www.CENTC251.org) for kore information. Gerard On 2003-08-04 16:51, Christopher Feahr chris at optiserv.com wrote: In my view, the EHR effort... partly by virtue of the inclusion of the record concept... is starting at too complex a level... at a point where we are almost designing a particular business management system in the standard. A rule-free standard model for the INFORMATION should exist first. From what I understand, SNOMED CT is a very good start on that. Also as a standard, we should make an effort within each care domain to model the actors, places, and things in healthcare, the relationships between them that are always true, and the relationships among the information elements that are always true. This can serve as a useful framework or high-level model for the much more granular and often unique process and information models of each local user-enterprise. -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 Leiden The Netherlands +31 71 5181388 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
HISTORY DATA SET IN EPR
Hi, As a GP with 20 years of experience in the Netherlands I learned that free text plus a not to complicated set of codes (ICPC) is sufficient for daily practice. We could generate automatic advice for medication based on complaints or diagnosis. ICPC contains roughly 2000 complaints, diagnoses and procedures. It will cover 80% of every thing a GP will encounter during the day. The provision of medicine is an art. The registration of all medical (and other) relevant facts and findings is retelling the story of the pati?nt. It is a narritive process. Have we ever seen a piece of literature completely written in complex codes? The study of Archetypes (see the OpenEHR website) will reveal that Archetypes plus free text plus codes will enable future physicians a lot of flexibility and expressive power. Much of the flexibility will depend on the ontology (medical knowledge and knwoledge of the world) behind the scenes. And bye the way. In the RD facility where I work we have a very powerfull tool for analysis of free text. Recently a lot of progress has been been at this. If the free text is 'enriched' with Archetypes this process of meaningfull data extraction will become much more easy. Gerard Freriks -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 Leiden The Netherlands +31 71 5181388 +31 654 792800 -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 From: Christopher Feahr chris at optiserv.com Organization: Optiserv Consulting Reply-To: Christopher Feahr chris at optiserv.com Date: Mon, 11 Aug 2003 07:32:52 -0700 To: Thomas Clark lakewood at copper.net Cc: Karsten Hilbert Karsten.Hilbert at gmx.net, openehr-technical at openehr.org Subject: Re: HISTORY DATA SET IN EPR Presently, each doctor and EMR software vendor is cooking up his own shorthand-language, and I'm suggesting that information should be reduced as much as possible to a standard set of codes. - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
openEHR security; Directed to Thomas Beale
On 2003-05-02 19:25, Bill Walton bill.walton at jstats.com wrote: Hi Gerard, Gerard Freriks wrote: /snip/ In other words: the OpenEHR can assume that the Access Control function operates as if it is a fire wall that executes a set of rules and that the Audit trail is the log with violations (Exceptions) the fire wall had to grant. The operation of the 'firewal' and audit trail are outside the scope of Open EHR. While I support the concept of seperating the access control functionality from the storage / retrieval functionality, I'm afraid I have to disagree, with all due respect, to the segregation of the audit trail and to what I understand your definition of what needs to be contained in the audit trail. The notion that the audit trail only log exceptions will be a non-starter here in the U.S., I think. I understand your remarks. But. The following information must be added to get a fuller picture of how I envisage things: -0- The context for my remarks is the discourse, using human and computer processable documents, between health professionals over time and space. My context is not updating databases using messages. -1- Electronic systems must provide at least the same quality in all aspects when compared with paper based systems. The quality can be better but never less. -2- Of course persons entering the system are logged -3- And only information is readily available to which one has rightful access because one is working in the same department the patient is in. All access to the information will not be logged in the audit trail. (paper based systems don't record where the eyes hit the paper and ink) I assume a high degree of social control in a department. -4- Audit trails in the sense that is recorded why, what, when, from where, by whom has used the exception path to reach information are needed when the requestor is overruling the access controls. -5- the preferred way of obtaining information must stay (as it always was) direct contact between health professionals either orally or by writing. My fear is that because anything can be recorded and tracked or traced we feel obliged to do so in the electronic domain. Example: The Data Registrars Office in the Netherlands is of the opinion that access to electronic medical records can be granted only by using two ways authentication (password AND biometrics) The only justification is that it is possible. But it is unaffordable and to complex to organise in the healthcare domain) -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Record Level Data Security; storage plus fixed and mobile transmission
On 2003-05-02 22:43, lakewood at copper.net lakewood at copper.net wrote: Security begins at the data storage level. Unless it can be protected at this level more sophisticated techniques applied to transmission and content will not be as effective as desired. Three common approaches are: 1)Data security 2)Data management and 3)Access to storage media-resident data, e.g., somebody's disk drive You leave out completely the legal, social control and organisational aspects. Technology isn't a silver bullet. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Record Level Data Security; storage plus fixed and mobiletransmission
Dear Thomas, At OpenEHR there is an emphasis on the exchange of documents but also on storage of objects in systems. What you are referring to is the first topic (messages). Gerard On 2003-05-03 19:52, lakewood at copper.net lakewood at copper.net wrote: Hi Gerard, Record Level Data Security has little to do with legal, social control and organizational aspects. I agree that these are important, and in many cases more important, than record level data security. They are more complex issues that are dependent upon factors varying from culture to informal/private business arrangements. To be complete others would have to be added. The approach taken was to start at a level where secure global electronic data interchange of healthcare records is possible, a possible model being the Association For Payment Clearing Services. http://www.apacs.org.uk/downloads/List%20of%20Standards5.pdf The perceived need is secure, standard record formats so that information can be accessed even though it was created under a system using a different record format. -Thomas Clark - Original Message - From: Gerard Freriks gfrer at luna.nl To: lakewood at copper.net; openehr-technical at openehr.org Sent: Saturday, May 03, 2003 2:40 AM Subject: Re: Record Level Data Security; storage plus fixed and mobiletransmission On 2003-05-02 22:43, lakewood at copper.net lakewood at copper.net wrote: Security begins at the data storage level. Unless it can be protected at this level more sophisticated techniques applied to transmission and content will not be as effective as desired. Three common approaches are: 1)Data security 2)Data management and 3)Access to storage media-resident data, e.g., somebody's disk drive You leave out completely the legal, social control and organisational aspects. Technology isn't a silver bullet. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements TIMED MEASUREMENTS
HI, On one hand there is the notion as used in HL7 where series of messages update databases producing a list of updated measurements. On the other hand there is the notion as used in CEN/TC251 and OpenEHR where documents are used to enhance the raw data by providing a human interpretation and advice by an expert using the updated measurements in the database. Gerard -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 Leiden The Netherlands +31 71 5181388 +31 654 792800 -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 From: Sam Heard sam.heard at bigpond.com Reply-To: Sam Heard sam.heard at bigpond.com Date: Mon, 27 Oct 2003 11:41:47 +0930 To: Bhupinder Singh bobdog at sancharnet.in, Thomas Beale thomas at deepthought.com.au, Openehr-Technical openehr-technical at openehr.org Subject: RE: Pathology requirements TIMED MEASUREMENTS Bhupinder The only values we are not wanting to show are those that are wrong - and have been changed in a later version. The idea behind this is to store the information in an openEHR system inside the Pathology service and then send an extract - rather than develop a lot of messages. Cheers, Sam - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements CONTRIBUTION - 2 versions at once
Hi, Only an attribute will not be enough. It has to be accompanied by rules. Information will be stored in various contexts and not always in the same system. The same information will be stored in separate contexts. A change in the status of the 'Lifecycle marker' in one machine will not result in changes in other machines, unless there is a replication service. It is unlikely that all systems will be able to deal with such a service. In order to handle this we need rules. My suggestion for a rule would be: the 'Lifecycle marker' is valid (maintained) in one system only. Moving from one jurisdiction to an other means that the person that takes responsibility for the admission of this information into a new jurisdiction/system sets the marker to: received and admitted. Part of the rules is a state machine that provides all the states of the 'Lifecycle marker'. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 From: Thomas Beale thomas at deepthought.com.au Reply-To: Thomas Beale thomas at deepthought.com.au Date: Mon, 27 Oct 2003 08:16:55 +1000 To: Openehr-Technical openehr-technical at openehr.org Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once That is why I am suggesting that all such Entries havea lifecycle marker. This is somehting which I think our colleagues at UCL have long had in their system, and I have never seen a scenario which I thought justified it until now... - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
connection between Reference Model and Archetype Model
Hi, Have a look atL http://www.centc251.org/ And find the new draft open for comments on the front page. Gerard -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 Leiden The Netherlands +31 71 5181388 +31 654 792800 From: Sebastijan Mrkus sebastijan.mrkus at ericsson.com Organization: Ericsson Nikola Tesla d.d. Reply-To: Sebastijan Mrkus sebastijan.mrkus at ericsson.com Date: Fri, 19 Sep 2003 16:26:00 +0200 To: openehr-technical at openehr.org Subject: connection between Reference Model and Archetype Model Can anyone post link or a reference to a document that describes connection between Reference Model and Archetype Model. We are currently working on a project that uses CEN ENV 13606 as Reference Model and we are trying to implement archetypes. Any suggestions would be greatly appritiated, Sebastijan -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030923/52879af9/attachment.html
Modelling Episodes in openEHR
Thom, It seems we are in agreement. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 04 Dec 2004, at 12:54, Thomas Beale wrote: Gerard Freriks wrote: Dear all, Am I correct to conclude and propose that: - *episode:* situation considered to occupy a time interval - there are at least 4 context's in which the term 'Episode' is defined: disease related (point of view of the patient), this kind of episode often has vague boundaries, and I think we have to rely on following LINKs in the EHR to find all its pieces. If I get bronchitis that seems to get better before it gets worse every two weeks, is this a single episode or many? I don't think it matters - what matters is being able to find all the information items relating to a given problem. And relating data in a specific context for a specific purpose that some times is defined in a group and sometimes defined by one actor for his own purpose. Episodes likes these are more general and NOT depended on business rules. treatment related (point of view healthcare provider), adminstrative contact related (point of view of healthcare institution), these two are I think possible to identify as being delimited by known points in time, as long as the provider has a clear rule for when they are providing health care, versus when they are not. They might be providing care in parallel with other providers of course - e.g. Dipak had a good example of patients on weekend leave from a mental health institution, who become the responsibility of the local GP for the weekend, but don't really stop being the responsibility of the institution. episodes like these are depended on (local) business rules that vary from place to place. insurance related (point of view payer) How re-imbursing institutions want to define episodes is something I don't know much about, but Tim Churches or someone may have something to add here. How does that work in NL, Gerard? I know there is a mixture of government and private payors. I don't know them either. But think of mergers between firms and new insurance products and updates within one firm. - sometimes the period is real and enumerated (/dd-mm-yy, ISO 8601 : 1988Data elements and interchange formats - Information interchange - Representation of dates and times/), sometimes indefinite (/one week ago, some weeks ago, ongoing, during, before, etc, as defined in CEN/TC251 EN1238 Time standard for health care specific problems/) I think such vague times can only be for clinical use (patient had an episode of bronchitis about 2 weeks go, lasting about a week). For billing or other computable purposes such as statistical studies, you have to be able to know which things are in and which are out. I agree. - thomas -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3103 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041204/72403de6/attachment.bin
Modelling Episodes in openEHR
The disease episode is about the patient and can and will be exchanged. Other episodes defined on the basis of local business rules will not be exchanged. GF -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 On 04 Dec 2004, at 16:44, Bill Walton wrote: I think any institution has to have a firm model for what it thinks an episode is Assuming that different institutions will adopt models that differ, what are the implications for the exchange of data and the creation of a lifelong EHR? -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 687 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041204/688bece1/attachment.bin
Modelling Episodes in openEHR
Sam, Is it correct to say that: - Each type of Episode will be an specific Archetype that maps starting at the folder. - What must be communicable generically is the disease type Episode since this can be true in many places. - The Non-disease Archetypes are based on local business rules and don't have to be communicated to others outside the own organization. So each organization will have its own Archetype that fits their business rules. - It will be wise to use in the Archetypes terms that conform to the CEN/TC 251 Continuity of Care standard. - Three proto-Archetypes defining the various episodes must be standardized in order to create interoperability. - Two non disease type proto-archetypes will be highly specialize-able. - The disease related proto-archetype will be of the kind that can not easily be specialized. New term (=concept): proto-archetype - A standardized Archetype. This proto-archetype must be the starting point for specialization in order to produce an Archetype to be defined and used in a local community. Bye the way. What types of standardized proto-Archetypes will we need? What are the rules for specialization? Which proto-archetypes can and can not be specialized? Or are we more subtle; to what degree? Etc, etc. Do we need accepted rules that govern the production and usage of Archetypes? Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 On 06 Dec 2004, at 03:08, Sam Heard wrote: Bill and all This is a very important consideration and one that we need to get right for lots of reasons. Tom has been proposing an aggregation approach - allowing us to find all data that relates to something - a disease, care at an institution etc. It is clear that there are aspects of the episode that are specific to the care setting and administrative and billing requirements. We could have a composition that held information about the administrative aspects of the episodefor billing purposes or secondary data collection. It would be possible to archetype an 'episode' folder to contain one of these - and possible to define what is held within it should that be appropriate. It is clear that a simple aggregation model is not enough, but we also do not want to have lots of folders to describe one episode from different perspectives. The Mayo can only have one episode per patient at any timethis ensures that the person who opens an episode is responsible for closing it - and summarising it, tying up lose ends etc. This is a very important quality issue in distributed care environments. But in the Australian setting where we have primary and secondary care separated - the notion of secondary care episode is largely a billing or funding issue - although we have discharge referrals back to primary care. In primary care, the idea of an episode - a single one at a time - is appealing to me - meaning it is non-routine care for the problems the person has. It stops what Michael Balint called the collusion of anonymity - a destructive outcome of 'shared' or 'parallel' care. Cheers, Sam -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3288 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041206/d0152127/attachment.bin
Modelling Episodes in openEHR
Hi, On 06 Dec 2004, at 09:10, lakewood at copper.net wrote: An episode at age 10 is not likely to be important at age 30, 40 or beyond. ?! An episode of appendicitis at 10, an episode where the spleen is removed, an episode of leukemia at 10, all are more or less very important, when talking about the disease related episode. In contrast the administrative related episodes are NOT important under must (non-legal) circumstances. Although it might be important to know for a relatively short period that because of hart failure the patient is admitted to a hospital every other week. The list of recorded episodes is very valuable to discern important medical facts from common colds, and bruises. It is the patients medical history where important medical facts are grouped. Do we have a list of use cases for each type of Episode? Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1063 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041206/8cedb77e/attachment.bin
Modelling Episodes in openEHR
wow, wow! GF -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 07 Dec 2004, at 06:46, Sam Heard wrote: Bye the way. What types of standardized proto-Archetypes will we need? There are some interesting ones potentially. visualisation is one that I am interested in. To cover external observation and all forms of Xrays, Ultrasound etc. The advantage is that if you are interested in the Liver - it would be easy to find all visualisations - at laparotomy, by ultrasound, CT. The price for such an approach may be too high - but I kind of like the idea of it. Visualisation.ultrasound or visualisation.xray.ctscan What else? Lets have a look at the CEN/TC251 General Purpose Information Components (GPICS) or HL7 v3 CMET's) as starting points. Visualisation on one hand might means the procedure and result as in a Dicom report. Or on the other hand a specialisation of the Observation GPICS where the focus is on the expert opinion about the result of the former 'visualisation-type'. We need at least two classes of archetypes dealing with obeservations (and possibly other topics): the procedure plus result and the expert opinion about it. What are the rules for specialization? There are the technical ones that ensure that a specialised archetype does not break the rules of the parent - some of these are working in the editor. Generally, specialisation is appropriate if a query on one archetype should return information even if it is in another. We need those things ecxplicitly in writing. They have to end up in CEN/TC251 EN13606 part 3. Which proto-archetypes can and can not be specialized? No rules as yet. We need rules for this and several other things. Or are we more subtle; to what degree? Etc, etc. Yes...we are learning a lot about this as we go. Do we need accepted rules that govern the production and usage of Archetypes? We do, and we need to put these together as we go... Who? How? Where is the list? -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2302 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041207/31eee120/attachment.bin
Modelling Episodes in openEHR
Hi, That seems a good suggestion. Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 On 11 Dec 2004, at 17:20, Thomas Beale wrote: And our current suggestion (from Dipak Kalra and myself at least) is that a special Composition be used in an episode-Folder to hold administrative data - i.e. in addition to all the clinical Compositions in the Folder. -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 526 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041212/478b3f45/attachment.bin
Episodes in openEHR
Colleagues, Consider the following as requirements from the Netherlands. The Dutch GP organization NHG has defined Episode as: An Episode is a chronological collection of medical data (episode items) of one patient and describes the state changes over time concerning one health problem. The name of the episode describes the health problem (health issue) and can be changed over time. The episode unordered list contains all episodes, open or closed. Episodes can have an attribute indicating attention Episodes can be closed and opened. Episodes can be joined and split One episode consists of episode items. Episode items are: report as the result of a contact, Prescription/Order, Diagnostic Archive, Correspondence. Most of Marten Spook's attributes stem from these Dutch GP requirements. I consider Episodes as an alternative view on the information collected. It is a list consisting of links pointing to registered information that is available in the system. The preferred place to store this list is the Folder. And then there are our DBC's (DRG's) One DBC is almost the same as an Episode. Gerard -- work -- Gerard Freriks TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 On 20 Nov 2004, at 02:42, Thomas Beale wrote: This is part of a discussion that started off the list. The need is to be able to model Episodes in openEHR, while remaining compatible with available structures. Currently, there is no Episode class (although this doesn't necessarily have to remain this way). Up to now, we have never been able to nail down sufficiently 'standard' requirements to satisfy everyone's idea of an episode.? Instead we have suggested that Folders be used as reference containers to Compositions considered to have occurred in an episode. The current EHR reference model shows this. More recent thinking on this issue: - on my recent visit to Mayo Clinic at Rochester Minnesota, I discovered that their idea of an Episode in the MICS system is a period of care overseen by a particular clinician. E.g. if someone comes in with an injury, the doctor referred to (by a GP or by AE) 'runs' the episode. Even if the patient sutains an MI while in hospital, and that becomes her main problem, and a cardiologist gets involved, the original clinician in almost all cases is in charge of the episode, and will make the discharge summary. An episode can be 'closed' on the MICS system, but can be reopened by some special operation, e.g. if erroneous information is spotted later on. I seem to remember that someone else can take over an episode - presumably if the original clinician becomes unable to continue giving care for some reason. (Someone from Mayo on this list might want to correct me if I have any of this wrong). - Maarten Spook of 2Cure, Amsterdam has some very typical requirements of an Episode, as follows: We think of attributes like: 1. startDateTime: the date-time the episode is started (medically) 2. stopDateTime: the date-time the episode has ended (medically). When present this folder is closed? 3. createdDateTime: the date-time the episode was created (administrative) 4. contributers: care providers and their role (participations?) It would be clear to see who had added info and who is responsible for this episode etc 5. structured annotation: a short description of the content / context of the episode My comment on this is: of the above attributes, it is the first 3, and maybe #5 which need to be associated with an episode as such. Contributors can be determined from the contributors to versioned Compositions in openEHR (remember Contributor is actually a class itself in the openEHR Common model). Let us consider if we could achieve this just using Folders, as a straw man proposal. 1. clinical start date time can be determined from the start_time of the first Composition in the Folder 2. clinical stop date time can be determined from the endt_time of the last Composition in the Folder 3. created date time of the episode - administrative. Depends on what this really means. The creation date time of the Folder representing the episode is easy - it is the time_committed in the audit attribute of the type VERSIONCOMPOSITION resulting from the class VERSIONED_COMPOSITION being a binding of VERSION_REPOSITORY to COMPOSITION. 4. contributors - as mentioned above, these can be derived from inspecting Compositions in the Folder 5. structured annotation describing episode. Usually this would be in the discharge summary, itself a Composition, containing narrative and links to previous Compositions Entries in the episode. However, does it need to be someting else? 6. Maarten also mentioned that in their system, they want to be able to close an episode
Archetype vs. ontology
Hi, An other property of the Archetype is that it is derived from a a model that models the structure via which information is stored/represented/ retrieved in a system. GF -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 23 Nov 2004, at 17:26, Carl Mattocks wrote: Philippe, Sam et Al : Seeking clarification .. Is it true to say : the real distinction between an Archetype and an Ontology is that - the role of an Archetype (item) is to provide contextual constraints the role of an Ontology (item) is to provide conceptual constraints an Ontology (item) concept can be applied as an Archetype (item) constraint an Ontology item must have object oriented properties e.g. it is composed an Archetype item must have data (info) properties e.g. it has a type a Set of Archetype items (whether or not linked to a template) may have info properties that are the equivalent of a particular Ontology (but not explicitly asserted) carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1107 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041123/24b94efb/attachment.bin
A patent application covering EHRs
Hi, How serious is it really? Is there anybody with a legal opinion? I only have a laymans opinion about this ridiculous patent. Gerard ps: A few snippets from en CEN/TC251 standard published in 1999. CEN/TC251 ENV 13606: 1. Scope This European Prestandard specifies messages that enable exchange of electronic healthcare record informationbetween healthcare parties responsible for the provision of clinical care to an individual patient. These messages allow information from an electronic healthcare record held by one health professional to be sent to another healthprofessional. The messages specified by this European Prestandard can be used to convey:? a complete copy of a patient's record as stored in one information system; ? parts of a patient's record that form a logically sound extract or summary of that record;? parts of a patient's record used for updating a parallel record on another system. The primary purpose of these messages is to support the provision of care to individual patients. The availability ofconsistent, continuing clinical care, when and where it is needed, requires appropriate and unambiguous communication between clinical professionals. The messages specified by this European Prestandard are designed to meet thisrequirement by enabling users of different clinical information systems to exchange electronic healthcare record information. Implementation of these messages will therefore assist the maintenance of timely and appropriate patientrecords. With a definition of Health care party: -- 3.39. healthcare party. Organisation or person involved in the direct or indirect provision of healthcare services to an individual or to a population. -- Met andere woorden. Hetgeen functioneel beschrven staat is omvat in de CEN voornorm voor het EPD. The concept Template is mentioned. Any input screen is a template. And before 1999 this concept was defined and in use. As far as Access Control is concerned Part 3 of the CEN/TC251 ENV 13606 is about the expression of elements needed for access control. 1 Scope This European prestandard specifies data objects for describing rules for distribution or sharing of electronic healthcare records in whole or in part. This European prestandard establishes general principles for the interaction of these data objects with other components and mechanisms within an electronic healthcare record application, thereby controlling the distribution of electronic healthcare records in whole or in part. This European prestandard establishes ways of creating information with associated security attributes. This European prestandard defines a methodology for constructing rules built from defined data objects, capable of being implemented using a range of techniques, to effect the control of sharing of electronic healthcare record data. This European prestandard establishes principles that allow security policies to be implemented and incorporated in order to ensure the safe use of the data. This European prestandard specifies a method for constructing an Access Log, that can be rendered human viewable, that records distribution of the data to which a Distribution Rule is attached. This European prestandard does not specify the mechanisms and functions that take part within the negotiation procedure and therefore fully automate the data distribution process. This European prestandard does not specify the mechanisms and functions that will allow some systems to continuously reauthenticate the data communication session and monitor its integrity. This European prestandard allows the sharing of records distributed in space, time or responsibility. This European prestandard does not specify the data objects and packages represented in an Information System. At this moment I have no time to browse further. But on the website of NIST more is to be found about Role based Access published before 1999. And persons like Bernd Blobel and Ross Anderson wrote about security in health care gf -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 23 Nov 2004, at 03:29, Tim Churches wrote: There is some concern here in Australia over a patent application lodged by the Pharmacy Guild of Australia over some rather generic features of EHRs. These concerns are reported here: http://australianit.news.com.au/common/print/ 0,7208,11467621%5E15319%5E%5Enb%20v%5E15306,00.html or here: http://snipurl.com/atst The application has been lodged under the international PCT (patent co-operation treaty), and it appears that country level applications have been lodged in at least the UK, Canada and the US, as well as Australia. At a glance, there would not appear to be much in the way of novelty in the claims, and several groups here in Australia plan to lodge objections
Archetype vs. ontology
Hi, I can buy this. But have you ever seen the UML model behind ICD, ICPC, or even SNOMED? I know I;ve seen the one behind the CEN/TC251 EN 13606 where a kernel model (UML) representing a generic document will be populated by Archetypes that are derived from a Archetype model (UML). Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 On 24 Nov 2004, at 17:29, Carl Mattocks wrote: HI GF : Do you agree that this can also be true for an Ontology . carl quote who=Gerard Freriks Hi, An other property of the Archetype is that it is derived from a a model that models the structure via which information is stored/represented/ retrieved in a system. GF -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 863 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041124/385a9fad/attachment.bin
Archetype constraints and interfacing instruments/DSS to an OpenEHR system.
Hi, We, at CEN are devoted to CEN/IEEE/ISO developments and not 'old rusty' standards. Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 On 29 Nov 2004, at 20:56, Damon Berry wrote: Sam, Thanks for the helpful comments Sam Heard wrote: I believe that DSS groups will be a major player in determining the final archetypes that are agreed at a high level. It seems to me that in the same way, archetypes will have great impact on the development of future EHR-compatible instrument interface standards. If instruments and instrument interfaces are required to provide information that is complete enough to be integrated into the EHR, then additional context information will need to be appended as the measurement values are recorded. Lets assume that a typical existing instrument interface was not designed to produce shareable EHR extracts - a safe bet in my view. Result: missing context info. So to ensure compatibility either, - the instrument interface is revised by the instrument vendor to satisfy the associated archetypes OR - an adapter on the EHR side of the interface adds the required context information prior to submitting it to the EHR-S proper. (not very nice) OR - some compromise is reached on the completeness of the archetype. (dangerous) OK - maybe I am exaggerating - but it would be interesting to pick a legacy instrument standard (say crusty old ASTM 1394-91) and see how it holds up. -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1658 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041129/e6c62e81/attachment.bin
Archetype constraints and interfacing instruments/DSS to an OpenEHR system.
Karsten, The advantage is that there will be no 3 or 4 competing standards, but just one. It seems enough. Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO-PG Zernikedreef 9 2333CK Leiden The Netherlands +31 71 5181388 +31 654 792800 On 29 Nov 2004, at 23:44, Karsten Hilbert wrote: We, at CEN are devoted to CEN/IEEE/ISO developments and not 'old rusty' standards. The advantage of which is what, exactly ? Karsten -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 537 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041130/1329336d/attachment.bin
Dr R LONJON Confidence indicator !
-1- Almost never a diagnosis is 100% certain. -2- Almost always a test result has uncertainty attached to it -3- Many times a conclusion is reached based on many uncertain and conflicting facts -4- Quite often a condition, a diagnosis, is assumed that gives rise to a treatment. Not indicating that the patient is suffering from this condition but using treatment as a test procedure. Doing nothing is such a test procedure. Eric Wulff (from Danmark) published philisophical texts about health care and these topics. gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 20 Apr 2005, at 13:58, Thomas Beale wrote: I'm wondering if there is a meta-algorithm of some sort lurking behind the scenes, which takes account of uncertainty in a note, and also severity of non-discounted possibilities, as a way of deciding what to do next. There is undoubtedly published work on this... thoughts? - thomas beale -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1072 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050422/bbb58527/attachment.bin
EntityNameParts
We must get used to the notion that patients not always have to provide their real names. And that in order to provide healthcare we need to know the real (administrative) identity. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 17 Mar 2005, at 13:50, Grahame Grieve wrote: At 11:29 PM 17/03/2005, you wrote: Richard is often abbreviated to Dick in English usage. No idea what the origin is - lost in the mists of time. So, if you get initial = D given = Richard you don't know that the D is an abbreviation for Richard. And if you do know that it is, there's no way to say so Well, is there a *need* to say so ? What's fundamentally wrong with just storing the D as a second first name along with Richard ? I probably am too much of a pragmatist. hi Karsten depends which hat I'm wearing. If I'm programming, then I probably won't care - delegate the problem to the user. If I'm wearing my standards hat, or writing a reference demographics server, then I would care Grahame -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1211 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050426/b5c55b72/attachment.bin
OIDs / II
Dear all, My ideas: - unique identifiers are numbers that are unique. - each collection of information that has an attribute with this unique number can be collected and presented as belonging together, - with one unique identifier per (pseudo)identity all information belonging to this unique identifier can be collected and presented as belonging together - this type of use is identifying documents (or parts of it) as containing information about the same person with a specific identity. - it is NO PROOF of the real identity of the person. That is a different matter. - When we have to uniquely identify persons we need other things than numbers. - Unique numbers must not be trusted. - Unique numbers that identify persons generate problems: identity theft. - Only knowledge that is known by the person, or features his body posesses, will help to identify persons. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 20 Apr 2005, at 12:43, Bert Verhees wrote: Dear Grahame, For example the CEN GPIC subjectofcare which has a property id The type is a Set of II The use is excplained as: An identifier or identifiers that may be used to uniquely identify the subject of care. Examples: social security number, health service number, hospital number, case notes number Please indicate where there is a mismatch between the intention and the use of II. CENTC251 could learn from that. It would be a great benefit to the standard if this would be sorted out. And if it will, then the need for an extra qualifier to tell which the type of identifier is presented, may disappear, depending on your solution Kind regards Bert Verhees -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1829 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050426/14704952/attachment.bin
EntityNameParts
Disasters or not. This is not what I ment. In real life we buy a loaf of bread without a full identication. In real life I get healthcare without the need for the care providers to know my name. And when I pay in cash they don't need my bank account number. The only need a unique identifier (set of) to find records filed previously. Any unique thing will work as well. A real name, address, data of birth, or my bankaccount, the date of my mothers birthday, a token, a phoney name, or an other unique thing like a series of scars on my skin, a photograph, my fingerprint, etc, etc Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 26 Apr 2005, at 09:56, Bert Verhees wrote: Op dinsdag 26 april 2005 07:37, schreef Gerard Freriks: We must get used to the notion that patients not always have to provide their real names. And that in order to provide healthcare we need to know the real (administrative) identity. When you build a system that is only usable when you have a working Internet-connection, in my humble opinion, this is a bad system. There are many situations where you don't have good networks, think of war, tsunamies, big disasters, maybe you want to register people for the healthcare they get, but if a stupid application refuses to accept a patient, because the OID cannot be resolved (when you say mandatory to a programmer, he will make it mandatory), tha application will be useless. But this example is beyond the scope of my problems (for now). Bert Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 17 Mar 2005, at 13:50, Grahame Grieve wrote: At 11:29 PM 17/03/2005, you wrote: Richard is often abbreviated to Dick in English usage. No idea what the origin is - lost in the mists of time. So, if you get initial = D given = Richard you don't know that the D is an abbreviation for Richard. And if you do know that it is, there's no way to say so Well, is there a *need* to say so ? What's fundamentally wrong with just storing the D as a second first name along with Richard ? I probably am too much of a pragmatist. hi Karsten depends which hat I'm wearing. If I'm programming, then I probably won't care - delegate the problem to the user. If I'm wearing my standards hat, or writing a reference demographics server, then I would care Grahame -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2855 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050427/e904c0ac/attachment.bin
EntityNameParts
In order to get proper treatment the identity can stay obscure. Identification is not a necessary condition for any treatment. Information is sometimes. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 27 Apr 2005, at 06:19, Grahame Grieve wrote: It's not the same. For various reasons care providers (may) need to properly identify their patients/customers. Healthcare may be provided on an anonymous basis under some circumstances, but the nature of these circumstances and the care provided will depend on jurisdiction -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 692 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050427/8f48b6a2/attachment.bin
Age and named quantities
Sam, You mean the 'age of a person' and not 'age'. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 31 Jan 2005, at 23:30, Sam Heard wrote: Age is time after birth - we are not going to change that. We have agreed that we need to record one more date in the demographic model - which is 'approximate date of conception', or 'expected date of birth' Which do people prefer - I chose the latter as it will probably be a cut and paste from the mothers record and does not get into the when did I conceive stuff. What do others think? -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 704 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050201/da6509b2/attachment.bin
Age
Dear Philippe, Thank you for your reaction. I'm interested in your model for cyclic events. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 27 Jan 2005, at 20:15, Philippe AMELINE wrote: Hi, In Odyssee, we have made the choice of : 1) defining the concept Age as an ellapsed time value 2) defining age related concepts (like child, old person...) as fuzzy sets I think that it is the only way you can manage this kind of thinks. We also have a (quite) good model for cyclic events ; I can describe it further if you want. Cheers, -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 717 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050128/193aeccc/attachment.bin
Age
Thomas, What you wrote with respect to age, is absolutely true. It is a notion defined at the knowledge layer. But expressed at an information model layer. On the level of the knowledge layer 'age' is more than a set of numbers indicating the time past since an arbitrary point in time. Next to 'age' there will be more notions that warrant the same discussions we have had. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 29 Jan 2005, at 02:07, Thomas Beale wrote: This all suggest strongly to me knowledge layer not information model layer! -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 721 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050129/bc222482/attachment.bin
Age
Dear all, It is fine for me when we can agree that we mean by 'Age' time after birth. How will we name and define concepts like: youth, post conception, post gestation, middel aged, elderly? Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 31 Jan 2005, at 19:10, William E Hammond wrote: For an age, I agree that the date of birth is adequate as long as you remember people do not age after they die. It is also convenient to have a reference time mark for many things, including conception, start of a course of treatment. Adjectives and nouns are difficult to put into algorithms unless the definitions are precise. Ed Hammond -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 802 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050131/dfe55f71/attachment.bin
Demographics service
Life is simple. Once we physicians know what to ask and why. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 05 Mar 2005, at 13:22, Bigpond wrote: And that's the problem that will keep the technical people in money for years to come. Not only must it be feasible it will be demanded by judges and courts if the EHR is to ever be truly adopted. Even now we have rules that all e-mails where a decision is made must be printed out! The paperless world has never been to court. It is feasible of course but complex. Flags are set when pages are viewed, there are intricate audit trails (terabytes). The fact that no one is doing it yet is that the litigation costs haven't risen high enough to balance the need to do it. Once a few specialists are sued for activities that can not be supported by the record and they known they were innocent then we will see some very interesting changes, either a reappearance of paper records (personal) or a new paradigm of image capture. IMHO of course. David -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1174 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050305/55b087ca/attachment.bin
Demographics service
TNO, the institute I work for, is of the opinion that the archiving solution is the preferred one. By the way. The topic started discussing demographic services. In general interoperability translates into the need for many shared points of reference. So for identities of persons as wel. Since persons are recorded in systems using a set of more or less unique features and since these unique features vary in time, one person will have many digital identities. This calls for a mechanism that unites all these variations on one theme. Eg the demographic server. Gerard -- work -- Gerard Freriks TNO Kwaliteit van Leven Wassenaarseweg 56 Leiden Postbus 2215 2301CE Leiden The Netherlands +31 71 5181388 +31 654 792800 On 05 Mar 2005, at 19:46, lakewood at copper.net wrote: Other: -If something crucial shows up on your monitor screen, do a Screen dump to a file and create a time/date stamped archive. It is a record and a mechanism exists to produce a permanent copy easily reproduced on paper. -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1095 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050306/fba2a5bc/attachment.bin
Demographics service
Hi, What is the definition, scope, function of the concept: demographic server in the context of OPENEHR? Thomas, Sam, Dipak: HELP! Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 06 Mar 2005, at 19:50, lakewood at copper.net wrote: Hi Gerard, My understanding is that demographic services collect, organize and process the characteristics of a 'population'. Presuming this, then I am a member of a large number of 'populations' regardless of intent. Narrowed to Healthcare the number of 'populations' shrinks but not to one. Given the fact that modern 'populations' are not 'stationary' it appears that there are many of us that can claim or hold membership in multiple Healthcare 'populations' which themselves are subject to new additions, e.g., those genetically sensitive to drugs of a particlular family. Identifying the indiviudal may have to be a separate operation. Identifying whether the individual is a member of a 'population', or 'populations's a subsequent task. A 'demographic server' is likely to be specific and limited in scope to address 'super populations', e.g., persons residing within the boundaries of a specific geographical region, e.g., Africa. A 'network' of such server could provide additional coverage. Since one can apply a variety of rules to the specification of an individual 'population', the 'rules' become significant especially where the 'rules' are chosen to affect results, all Diabetes Patients in the London area. Due to a number of reasons one may not be able to claim that London-area Diabetes Patients are the same as those in other regions, and, of course, that the Healthcare systems are the same or equivalent. Foundational is 'personal identification'. Without it a 'demographic server' is handicapped. Hence a good test for the server is a seriously injured person arriving at a Healthcare facility unable to communicate with no other form of identification. Since there are many other 'issues' and 'factors' important to the design, development and deployment of a 'demographic server' one may have to accept discussions that attempt to integrate topics. They are valuable RD efforts are results-oriented expectations are very likely to increase quickly. Regards! -Thomas Clark BTW: I tried to avoid bringing 'Public Health' into a discussion about 'demographic servers'. That would have been lengthy! -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2567 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050306/5bb8ff52/attachment.bin
Authenticity Issues [was: Re: Demographics service]
Hi, It is known for quite some time that digital signatures are not the best solution to encrypt information that has to be archived. For functions like this we need a real person/organisation that provides this archiving function. see by Ross Anderson: http://www.usenix.org/publications/library/proceedings/ec98/ full_papers/anderson/anderson.pdf Gerard -- work -- Gerard Freriks TNO Kwaliteit van Leven Wassenaarseweg 56 Leiden Postbus 2215 2301CE Leiden The Netherlands +31 71 5181388 +31 654 792800 On 07 Mar 2005, at 02:02, Sebastian Garde wrote: Hi, There is another issue with digital signatures in the context of EHRs: Their value decreases over time and with them the value of digitally signed documents as legal evidence. In other words: securely signed documents don't necessarily provide a secure basis for verifying authenticity for the required time-span of EHRs (30 and more years). This is due to the following reasons: - the employed cryptographic algorithms and the keys lose their security qualification in the course of time. (algorithm may found to be insecure, key length may be too short for increased computer power,..) - It cannot be guaranteed that the directories and documents needed for the verification of the underlying certificates are available for 30 years or more. In addition, the use of digital signing procedures is often insecure and information for the subsequent evaluation of the actual security is missing. To achieve high conclusiveness of digitally signed documents and to realize their integration into practical use, the documents complete life cycle ranging from generation of the document, generation of the signature, presentation, communication to (long-time-)archiving and later use have to be taken into account in a comprehensive way. For a truly long-term-solution for EHRs, a solution must be provided for this problem. If you are interested in details, see http://www.archisig.de/english Further, signed data may - of course - not be changed in order to keep electronic signatures valid. But when data has to be exchanged across networks, or in context of systems migration, such changes are inevitably occuring. Trying to avoid this with the help of new standardized and stable data formats contradicts experiences (although openEHR itself might be a solution for this problem). So, procedures are necessary to convert signed documents and preserve their evidence value (legally secure transformation). See http://www.transidok.de/index-en.html for details. Regards, Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2674 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050307/1216af1f/attachment.bin
archetypes and class constraints
The beauty of OpenEHR (and CEN/TC251 EN 13606) is the fact that we have a reference document model that because of its stability help store and retrieve persistent documents over long periods of time. Being able to change the reference document model will create problems by to much divergence. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 08 Mar 2005, at 01:58, Carl Mattocks wrote: I vote for the pragmatic approach when we don't control the reference model -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 633 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050309/18564377/attachment.bin
EntityNameParts
CEN/TC251 has an european standard: General Purpose Information Components. These 170 GPICS are proto-archetypes that can be contrained into archetypes. One of those is the proto-archetype for Patient demographic information. In the institute where I work we used the GPICS to make an information domain model of one sector in Dutch Healthcare: pediatrics. All the GPICS we needed we available. One GPIC had to be changed in order to become usable in the Netherlands: the demographic one! Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 11 Mar 2005, at 01:26, Thomas Beale wrote: You will be unsurprised to learn that we agree with USM Bish, and that names and other demographic entities should be archetyped. We don't seem to have a person name archetype yet, but you will get the idea from the location address one at http://www.openehr.org/repositories/archetype-dev/latest/adl/ archetypes/openehr/demographic/openehr-demographic- address.location_address.draft.html. I believe the approach of trying to have these as types in a RIM is problematic, for exactly the reasons Bert mentions. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1385 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050311/f3b8d219/attachment.bin
EntityNameParts
Dear colleagues, The CEN standards as told before, are consensus products at an abstract level. This implicates that they need an Implementation specification in order to be usable. You and others must produce those. OpenEHR is such a forum. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 11 Mar 2005, at 09:09, Bert Verhees wrote: My problem is not that there are areas which are not covered by a GPIC. But I am not the person to judge that. I am a programmer with some experience in medical informatics. My problems are in the area of technical implications about how details are worked out, or not worked out. The problems I mention are minor issues about details. I have more then I mentioned on this list. And it is impossible to wait for a committee to finish discussions and being uncertain about the outcome. Let me see how much time the responsible committees need to address the problems I mentioned. I can afford to wait three days. My projects are under time pressure. Medical Informatics in the Netherlands is a very much closed society. A lot of people do not discuss much, do not help each other, are not honest, hide their weaknesses and misunderstanding. A GP in the Netherlands who writes once in a while to a mailinglist, which is (not surprisingly) called Openkaart (meaning: Open Information Exchange), which of course it is not, he wrote: ICT is an Image of reality, this makes painfully clear a lot about the Dutch healthcare -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1662 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050311/f963a139/attachment.bin
EntityNameParts
Extending qualifiers is allowed. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On 11 Mar 2005, at 13:42, Bert Verhees wrote: Op vrijdag 11 maart 2005 12:36, schreef Karsten Hilbert: I forgot to mention one solution we could use in GnuMed: Attach another name to a person (they can have any number of names), put the initials in one of the fields and mark that name (eg set the comment) to be only initials. This is done really smart in CEN, they have an EntityName, which consists of a set of EntityNameParts, the number is unlimited, but the qualifier-possibilities are limited. The only way is to add a qualifier, that is extending the standard Not clean but doable. Karsten -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1057 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050311/8f12cede/attachment.bin
ADL to XML Schema
Hi, I'm only the convenor of the CEN/TC251 wg1. For more detailed information you need to read the e-mails by Dipak Kalra, Thomas Beale and Sam Heard. In the text below soem comments. -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO Quality of Life Wassenaarseweg 56 Leiden PostBox 2215 22301CE Leiden The Netherlands +31 71 5181388 +31 654 792800 On 10 Mar 2005, at 18:29, Jose Alberto Maldonado wrote: Hello, We have just read the message bellow and honestly we do not understand anything now. We supposed that EN13606-1 reference model could be used as reference model for developing archetypes. EN13606 part 1 is a generic model of any document, with versioning and attestation. EN13606 contains an UML model of the Archetype. You can read in prEN13606-2 (last version February 2005), section 1.3. Communicating archetypes: It is the intention of both CEN and HL7 that HL7 Templates and EN13606 archetypes be interoperable. One question arises are these EN13606 archetypes different from OPENEHR archetypes?. Archetypes are archetypes at the clinical level. And can have facets. An EN13606 facet when constraints are applied to the EN13606 kernel and an OpenEHR facet when constraints are applied to the OpenEHR kernel. Could you show some examples of clinical concepts that can not be expressed as archetypes derived from EN13606-1 reference model?. thanks in advance On dj, 2005-03-10 at 17:19, Thom Thomas Beale escribi?: Alfonso Mata wrote: Hello everybody, We're working at University of Zaragoza (Spain) on a EHR system. We want to conform to 13606 and make use of ADL-based archetypes. We are just starting and we have lots of doubts about how to implement and apply all concepts. These are our questions: - How 13606 is applied to built ADL archetypes? Is it already possible? - Is it possible to obtain a XML-Schema based on 13606 from an ADL file? - Is ADL parser in openEHR site the only one to make use of it? It does not make any real sense to make archetypes literally based on CEN 13606. Archetypes have a very important requirement: to be targetted to an informatoin model which acts as a base ontology. In openEHR we use the openEHR reference model fr this purpose. This is what allows you to write an archetype for somehting like Apgar result, which needs to use concepts like OBSERVATION (with properties data, state and protocol), HISTORY (with properties events, origin), EVENT (property data), and varous data structure types, like TREE, LIST, TABLE and SINGLE. EN 13606 is not designed directly to support archetyping; it is designed as a lowest-common denominator EHR data interoperability model, with support for transmitting archetyped information. This is not the same as providing sufficient ontological definitoins to support the building or use of archetypes. If you were to use EN13606 literally for archetypes, you could only use ENTRY, CLUSTER and ELEMENT; you will see that trying to define most clinical concepts with such a weak ontology will be annoying difficult, error-prone, and ultimately will not engage clinical professionals. So openEHR currently offers at least part of a base ontology for building archetypes, with concepts of sufficient strength to make higher-level clinical concepts easily expressible. In the near future, we intend to propose the creation of an agreed base level ontology reference model, expressed in UML, for use by everybody for buiulding archetypes. We will include the core of the openEHR reference model for this (from COMPOSITION down); but we want other organisations to think about what they need to see in this. There are other reference models such as the Danish G-EPJ which have clean concepts which may need to be in this base ontology; also ENV 13940 (continuity of care) models need to be analysed for possible contributions. We will propose this base ontology at the next CEN working group meeting. I believe people will agree in principle. A data mapping is also being defined between openEHR (and later, the common base ontology) and EN13606. This wll enable 13606 to fulfull its purpose, which is to move data faithfully between EHR sites, including data which has been archetyped in those sites. But please don't try to directly archteype 13606 information structures - you will be going down he wrong route! - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4771 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050312/aac36bea/attachment.bin
SubjectOfInvestigation
Dear Tom and Bert, The QA was done primarily by Edgar in his project. When improvements are needed I see two processes. -1- in CEN a new version. -2- in ISO in the work on CIC's. In the mean time we can maintain a file with the lists of proposed and the agreed changes. Who will maintain these lists? Gerard ] -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO Quality of Life Wassenaarseweg 56 Leiden PostBox 2215 22301CE Leiden The Netherlands +31 71 5181388 +31 654 792800 On 23 May 2005, at 18:21, Tom Marley wrote: Bert, ? Although very busy I am looking into this area.? ? The underlying problem may be that there was so little QA at the time and I feel very strongly that as structures are used there needs to be a proces which allows corrections/improvements and a dissemination of these. ? Whatever we decide in this area will be 'informally' distributed throughout the TC251 community. ? I will be in touch and we can discuss options. ? ? Regards -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1066 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050524/bc640446/attachment.bin
The Uncertainty Decision was: Dr R LONJON Confidence indicator !
On May 7, 2005, at 3:12 PM, Thomas Beale wrote: ...so it seems to me that the indicator of what to do next when a differential diagnosis is recorded relates strongly to the innate characteristics of the conditions recorded, not just the doctor's opinion of how likely it might be. If angina pectoris is a possible diagnosis for burning chest pain at 5%, with the most probable diagnosis (in the opinion of the physician) being gastric reflux at 95%, and it is a 55-yo with a family history of coronary heart disease, I presume that the angina pectoris possibility is the one that drives the next steps? How are the confidences really decided? In all cases what is recorded is the personal opinion of the healthcare provider. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050527/ddf67ffa/attachment.html
openEHR-EHR-COMPOSITION.Report.v1draft
Andrew, What you describe is an Organiser Archetype. An yes they belong to an reference model. But not the ref Model EN13606 part 1. They are derived from the meta-Archetype model. This Organiser Archetype will define all the things you wrote. The Organiser Archetype will be constrained from a more generic Any- Report Organiser Archetype. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On May 26, 2005, at 2:48 AM, Andrew Goodchild wrote: Hi, I was looking at the composition archetype for ?report? that comes with the archetype editor. The archetype constrains a composition to include information about a request identifier, requesting clinician, contact details, request date, report identifier, copies to and referrals to. Many of these things are also in common with standard tags in CDA. It seems to me that many of these fields actually belong in the reference model and not in an archetype. Does anyone think we need to extend the reference model instead? -Andrew -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050527/0b6d2f49/attachment.html
The semantics of archetype Specialization
Or only against the meta-Archetype model Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands +31 252 544896 +31 654 792800 On May 26, 2005, at 2:37 AM, Andrew Goodchild wrote: Hi, Does anyone know what it actually means to specialize an archetype? And what the rules are? I looked at the archetype editor and created a specialized archetype of another. The editor seemed to just copy the parent archetype and then allowed the user to change anything about the archetype. For example, I can now make a mandatory field optional, or I can extend a parent archetype with new mandatory fields that don?t exist as optional fields in the parent archetype To me this particular example is not safe as one of the basic rules of specializing archetypes is you should be able to validate any new specialized EHR data against the parent archetype. -Andrew -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050527/8581ea13/attachment.html
uncertainty in medical problem solving and decision making (Was: Dr R LONJON Confidence indicator !
On Apr 27, 2005, at 8:19 AM, Arild Faxvaag wrote: We could say that physicians _infer_ diagnostic hypotheses based on - knowledge of the tentative underlying disease, - the patients subjective experiences - phenomena registered in the patients body In any case it is a subjective statement and is a professional opinion based on more (lab results, x-rays) or less (patient history) objective data. Phrases such as cannot be exluded might be due to, probably, definitely, beyond doubt are statements of probability of the inferrence being correct (and what to do next). Inferrences expressed in the subjective statements documenting the treatment of the patient. Can one say that diagnoses belong to the class of statements whereas the disease itself belong to the class of natural phenomena? Disease is an abstraction of reality that for the moment, for the next decision is considered to represent the reality about the health of the patient. Diagnosis is the professional but subjective opinion about a disease of a patient. There is a continuum: Real pathological, fysiologiscal phenomena in a patient. Certain manifestations of these phenomena. That are (or are not) experienecd by the patient of an other person. The arrousal of distress, anxiety, etc, triggering a visit to a physisian. What is said (or not) about the manifestations of the phenomena during the visit. And how it is said. How it is measured and documented. What is understood of what was said or measured about the manifestations of the phenomena. How all this was mached to the state-of-the art knowledge, or interpreted in the context of a limited amount of available knowledge. What was recorded about all these steps above. How the same person (or others) interpret the recorded 'facts' at a later stage So what do we record in an EHR? And what do we interpret readingan EHR? Then ... What is certain? And what is uncertain? Certain or uncertain in what domain, in what line above, at what level of the whole described continuum? In ?25% of the extremely wel researched patients in one University Hospital we not diagnosed correctly during their life time. As could be concluded after an autopsy. So what do we really know about disease and complaints? What is certainty? What is it refering to? Do we understand this mine field well enough? The diagnosis establishes a relation between the subjective experiences / phenomena and the disease that induces those symptoms and findings. Example: Experiences and phenomena: Pain in the wrist joints, feeling of joint stiffness, joint tenderness, joint swelling, elevated sedimentation rate. Diagnostic inferrence: Rheumatoid arthritis. Relation: Might be induced by/due to Can statements of probability be considered statements regarding the strength of these relations?? This is what they are at best. Comments on this? -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050528/26059551/attachment.html
Templates - should we record which are used?
Dear Sam, When a Template is shared by to communicating parties we will have to record this in the EHR. This is because this is the Information part of the contract the communicating parties have. It is one that pertains to their communications. When the Template is used to store information I consider this a contract as well. The Template either has an ID or is identified by the tree of constituting archetypes. Gerard Freriks -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO Quality of Life Wassenaarseweg 56 Leiden PostBox 2215 22301CE Leiden The Netherlands T: +31 71 5181388 M: +31 654 792800 On 20-okt-2005, at 9:55, Sam Heard wrote: Dear All, We have been discussing the issue of templates and whether we keep an identifier of a template in the data. My concern has been that this ID might be seen as an absolute constraint on the data, whereas the precedence of constraint must be: The data must conform to the reference model The data must conform to the archetypes The data must be complete The template can be invoked to ease data entry. What this means is that when data is already present, even if it does not conform to a template (which may have been used as a guide when entering data) it must be allowed. Clearly an application may restrict data entry to the template (this is an application issue) but it cannot impose a template on data already gathered. Keeping a template identifier in the EHR is then a statement only that a template of some sort was used in creating the data. This template may be in a form that is generally available (eg ADL) or a specific local template implementation - there is no need to use a generalisable form of template within the openEHR framework - though it has advantages. Having said that, it is clear that it may be useful and I would suggest that we consider an optional string attribute at the composition level that allows recording the id of a template used to form the composition. What do others think? Cheers, Sam -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. Ltd. Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) Ph: +61 (0)4 1783 8808 Fx: +61 (0)8 8948 0215 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051020/8b6a3de3/attachment.html
removal of data
Dear all, In the paper world, I know, it is clear. A document with legal implications can never be destroyed without any trace. A document with legal implications can be removed from a registry in one place and moved to a special registry, folder, cupboard, etc. And the same is true for data entered (and attestedand therefor with leagal implications) in the paper file. What is in it, stays in it. It is explicitly forbidden to remove, scratch out, made unreadable, etc. The only way is to annotate incorrect data/information and not use it or send it to others. In other words, in the paper world in the Netherlands, we only know the logical delete. What has happened, has happened, we can not falsify history, is the bottom line. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 21-apr-2006, at 23:11, Thomas Beale wrote: William E Hammond wrote: Result, we need to have the ability to remove data physically and completely from the EHR. To leave the data is a breach of privacy. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060422/eb3df418/attachment.html
Pathology numeric values not supported in DV_Quantity
Folks, I will repeat myself. You are talking about a data type. This DV_Quantity is a number. The question is how do we embellish this data type and the number it presents with extra codes/numbers to indicate: types of certainty/ uncertainty, and statistical distributions. The only real meaning of an extra attribute as part of DV-Quantity pertains to the number given and not the meaning (interpretation). The extra attribute in DV-Quantity will provide information about the precision of the number, only. Any extra information is a property of the concept in which DV- Quantity is used. E.g. certainty/uncertainty, distribution, etc. It is related to the specific concept and its context that is being expressed and not the expression of a number/data type. ~, statistical distributions, etc will have to be expressed at the level of Concept definition and therefore the Archetype. Greetings Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 21-apr-2006, at 17:12, Thomas Beale wrote: this seems pretty close to a correct model. Slight corrections I would suggest are: - I am still uncomfortable with '~', since it seems to mean approximate, but we don't know how approximate... - does None mean a) none recorded (i.e. don't know, i.e. same as '~') or b) no accuracy, i.e. an exact value (reasonable for some things, e.g. the answer to the question number of previous pregnancies)? - in the case of a statistical distribution, one value may not be enough to characterise the limits, since the distribution may be asymmetric (I don't remember enough beyond normal/T/Chi2 to remember if there are distributions that need even more parameters). The question for us in openEHR is how much to implement of such a model: we have to be driven by real use cases. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060422/0fc646a3/attachment.html
removal of data
Dear Bert, Reading again a thick report by our Royal Dutch Medical Association about the interpretation of this pecific Dutch law my opinion is NOT changed. In a separate e-mail you can read some relevant pages. In summary. 'Information can be destroyed' is the text. There are two important conditions when it is not allowed to destroy information: - because of legal reasons - because of a substantial interest for others not to destroy it. An example is a legal process, or genetic information. What is not explicitly discussed in this report is the use case where decisions have been made on the basis of information that the patient wants to remove. In my opinion in this use case the information can never be removed physically or logically in the context of these decisions and the legal implications. But it must be removed logically in the context of information that can be transmitted to others. Later in the report there is a chapter on the EHR and deletion. They explicitly mention that deletion in the electronic sense means destruction of the hard disk and CD-rom, etc. This is not possible. A pragmatic solutions in terms of a well behaved Information system, implicating logical delete plus specific business rules, is the optimal solution. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 22-apr-2006, at 10:20, Bert Verhees wrote: Gerard Freriks schreef: Dear all, In the paper world, I know, it is clear. A document with legal implications can never be destroyed without any trace. A document with legal implications can be removed from a registry in one place and moved to a special registry, folder, cupboard, etc. And the same is true for data entered (and attestedand therefor with leagal implications) in the paper file. What is in it, stays in it. It is explicitly forbidden to remove, scratch out, made unreadable, etc. Sorry Gerard, in my opinion you are wrong, article 455 of WGBO (law of protection of personal data) states very explicitly that a patient can demand destroying of his record. I wrote this two days ago. The holder of this record must obey within 3 months after demanding, and there are some exclusions, but the fact is that there are situations where those exclusions do not apply. So permanent deletion of records is a demand of the law. Bert -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060422/47908ed5/attachment.html
Pathology numeric values not supported in DV_Quantity
I agree. A workshop, moment of reflexion, is needed. We must understand better the real facts, the use cases, the requirements, before we come to wrong constructs in the wrong models or the correct ones. Next we need to use the same definitions for: Data Type, Composit Data Type, Archetype. We need a common understanding of the function and meaning of Class, its Attributes, and Data Types. (Data Types are used to define the interface at the field/number/text level with other system components) Gerard Data Type, (e.g. a Floating Point Number) Composit Data Type, (e.g. Floating Point number, plus truncation) Archetype, (e.g. Measurement and its interpretation: ~, , , , , good, bad, not to be trusted, etc, etc) -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 22-apr-2006, at 10:13, Thomas Beale wrote: Tim, I agree with the workshop idea, and assume that it could at least be done in Australia as a starting point. Thus, for the short term, I am inclined to add only the very simple , , =, =, = indicator, and possibly consider the ~ one (since these at least allow us to properly represent very low and very high path test values that are sent as 5 and similar). The complex stuff that Tim has described below needs proper modelling and in the end will lead to new data types (and as Gerard says, it may well lead to something in the archetypes). As with everything, we need to really understand the exact requirements first, and that probably won't happen without a workshop. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060422/372e9677/attachment.html
removal of data
Friends, Data, information and knowlegde exists, can be interpreted in a spefic context, only. Data, information and knowledge without a context can be considered garbage. It can not be interpreted faithfully. It is nothing more than a string of codes. Always data, information, knowledge will be used outside the original context. It will be very difficult to erase it completely. The consequence is that when the context is removed from the data it can no longer be interpreted faithfully and therfor be used correctly. Logical removal is an example of this. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 24-apr-2006, at 9:23, Bert Verhees wrote: It would be possibe to gather all records (this always confuses me: an EHR is something as one single composition?) belonging to a patient and remove them, without leaving evidence it ever existed? Because, that is what the Dutch law demands to be possible. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060424/9c99493e/attachment.html
Pathology numeric values not supported in DV_Quantity
Dear all, The CEN EN13606 EHRcom standard is using an attribute to indicate that 'something is going on' and that precautions must be taken. Resulting most often in the need for human intervention. Is such an attribute a possible intermediate solution for the problem here? Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 26-apr-2006, at 15:24, Karsten Hilbert wrote: Much to my dismay a quick grep over a couple hundred results idling in files on my machine doesn't yield a = or = offhand but I'm positive I've seen it before. When I come across one I'll post it to the list. Checking the lab data transmission specs confirms that the result can be a free-text field which easily allows for any of the discussed accuracy modifiers. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060426/6b6eb88e/attachment.html
Normal and other ranges
Hi, My personal thoughts. In general the normal range is dependent on the type of lab method and specific lab and valid in a particular context (male, female, old, young, time, etc) So the information can be provided by the lab only. They know (should know) what all the normal ranges in all relevant contexts are. Of course for the purpose of providing lab results archetypes will be produced. In these lab-reporting archetypes there must be a spot where this type of information can be provided. IT techies think many times that absolute figures are very important. In general trends provide more useful information than single absolute figures Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 -- work -- Gerard Freriks, arts TNO ICT Brassersplein 2 Delft, the Netherlands T: +31 15 2857105 M: +31 653 108732 Gerard.Freriks at TNO.nl On 31-aug-2006, at 19:20, Thomas Beale wrote: technically there is nothing stopping it, but it would almost always be the wrong thing to do, since the normal range of a Quantity is there to carry the actual normal range for the particular analyte in question, for the lab, and for the patient. So if it is serum sodium, the range will still depend on all of these things, and cannot be archetyped. The intention is not to use archetypes to standardise these values, but to provide a place for labs to put the specific normal range values that applied for each analyte, for the particular patient, and remembering that each lab has slightly different instrument settings. Probably what you are looking for is the normal range reference data - like what you see in a pathology book, or what any physician knows for all of the main vital signs and other measurable things. We consider this to be reference information, like terminology, but for quantified values. While much of it is published in paper form, as far as I know there is no recognised way to represent quantitative range data in a standard computable form (i.e. in the way that you can get Snomed or ICD10 in a computable format). This is needed. But archetypes are not the place to standardise this - archetypes are about defining content structures, not domain reference knowledge. - thomas beale -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060831/7cba880b/attachment.html
Term binding in Archetype Editor: Definitions, Rules, Quality Control
Dear all, A few thoughts about this topic of Terminology Binding and Archetypes. In essence it is the topic of the Boundary Problem. Archetypes are a solution for this problem. But in order to do so we need agreements on a few things. We mus be extremely clear what we mean when speaking about binding terminologies in archetypes. Are we talking about Archetypes or Templates? (design-time versus almost run-time? Generic structures versus locally agreed structures?) Are we talking about 'Label' or ' Data fields' or ' Archetype slots'? Are we talking about Internal or External coding systems? Are we talking about General External Coding Systems or specially edited sub sets of External Coding Systems, like Oceans Terminology Server and editor provide? (Oceans product creates sub sets of a coding system to be used in a specific context. And acts at as a new refined, restricted, external coding system derived from a feeding general external coding system) What will be rules that govern these things and prevent hazards for patients and healthcare providers? Using the archetype editor we can provide bindings to Generic Basic Archetypes, Specialised Archetypes but also to Templates (Organising Archetypes) and Specialised Templates. Specialisations can be made for specific clinical (sub-)domains or legal jurisdictions. Archetypes define what maximally can be recorded about a clinical concept. Templates define what minimally must be recorded in a specific context, as the agreement between two or more communicating partners. Most (refined) constraints will be applied in Templates. Archetypes need some terminological bindings. Since they are general it can not be fixed fully at design time to what external terminologies they can be bound. Primarily they will use internal codes. In particular controlled circumstances a clinical domain might adopt a specific external coding system to be used in Archetypes designed for that domain. Most codes (internal and external) used in Archetypes will code 'labels' and less data fields. When data fields are bound to a specific external coding systems there will arrise the need for a similar Archetype but bound to an other coding system. This will need an Archetype Ontology where we can create a mechanism that establishes that two archetypes express the same clinical concept but in a different way, using an other (internal or external) coding system. In the world of Templates things are different. This is a space that is much less controlled. Local/regional/national agreements have to be made on the finest detail. Most codes will be used in data fields. A lot of local freedom will be necessary. I have not extended the discussion of binding Archetype Slots to a coding system that is used in connection to 'The Archetype Ontology'. Archetypes and specialised archetypes have to be subjected to quality control in order to prevent hazards, because of errors and non- interoperability. EuroRec (the European Institute for Health records) is executing an Europ[ean project: Q-Rec. Q-Rec will, among others, will realise an Archetype and Template Registry. Its main purpose is to realise: Quality Labeling and Certification of EHR-systems. This will have to include Archetypes. Eurorec will organise quality control of the archetypes and templates to be published. It might be a good idea to involve them. Helpful in this respect is that: - there is an agreement between OceanInformatics and EuroRec, - several players from OpenEHR and CEN/tc251 EN13606 are members of the Q-Rec consortium and EuroRec, - persons active in EuroRec and OpenEHR take part in worldwide developments on Archetypes/templates, Semantic Interoperability, discussions on the deployment of coding systems. Greetings, Gerard -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On 19-dec-2006, at 9:56, Williamtfgoossen at cs.com wrote: In een bericht met de datum 18-12-2006 20:44:14 West-Europa (standaardtijd), schrijft Thomas.Beale at OceanInformatics.biz: This is not an unreasonable request - it would not be particularly difficult to implement in the specs or the tools, if we know what to implement. We have to be careful with Snomed licensing issues however when the terminology is snomed... I think there is no reason to be careful if within a realm. Key is to take care where to apply and where not. My earlier comments on binding not only to one terminology but to have mapping tables with synonyms applies here too. William -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061219
ontology, information models, archetypes - a perspective
Thomas, Thanks. What you are saying is: - we have the real and other worlds with objects and our present understanding of it, - and we have the world where we document what has happened or will happen. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 7-jan-2006, at 5:03, Thomas Beale wrote: Dear all, for those interested in how ontologies (like snomed-ct for example), information models (like openEHR RM), and mediating elements (archetypes, templates) can be understood in perspective, I have produced a short powerpoint slideshow on the topic. See http://www.deepthought.com.au/health/tb_ontologies.ppt. - thomas beale -- __ _ CTO Ocean Informatics (http://www.OceanInformatics.biz) Research Fellow, University College London (http:// www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060107/4561bcce/attachment.html
[GPCG_TALK] Archetype Maintenance
What XML DTD's or XML-schema's are for characters/text are Archetypes for Information. Therefore both Information and the Archetype much be stored locally. Gerard -- -- Gerard Freriks, MD Convenor CEN/TC251 WG1 TNO Quality of Life Wassenaarseweg 56 Leiden PostBox 2215 22301CE Leiden The Netherlands T: +31 71 5181388 M: +31 654 792800 On 8-jan-2006, at 10:17, Tim Churches wrote: Thus, archetypes need to be stored, permanently, with the data. This implies that each and every openEHR/archetypes storage system must be able to permanently cache (that is, archive) each version of every archetype definition it has ever used to store any data. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060108/bf91731e/attachment.html
[GPCG_TALK] Archetype Maintenance
Information is exchanged in communities. All clinical information belongs to the healthcare domain. When clinical concept models (Archetypes) are expressed using an Open International Standard like the CEN/tc251 Archetypes, both the Archetype expression and the constituting clinical concept models are not owned in a commercial sense. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 8-jan-2006, at 10:17, Tim Churches wrote: If the argument above - that there is a need to permanent cache or archive copies of archetype definitions with the data which relies on them - then all archetype definitions need to be licensed in a manner which permits users to keep permanent copies of them. My (limited) understanding of copyright law is that such rights are not automatically or implicitly granted - thus an explicit license to keep permanent copies of archetype definitions will always be needed on every archetype definition. Furthermore, if an end user wants to transfer his/her data which happens to be stored using an archetype definition for which the copyright is held by someone else (which will usually be the case, since end users will rarely author their own archetype definitions, especially de novo ones), then the archetype definition used to store the end user's data must be licensed in a way that permits the end user to redistribute that archetype definition to third parties, without the need to ask permission from the copyright holder of that archetype definition. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060108/845bb6ed/attachment.html
[GPCG_TALK] Archetype Maintenance
If enough Archetypes are produced by scientific communities and associations and published IP free, then what is the problem? Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 8-jan-2006, at 21:49, Tim Churches wrote: Gerard Freriks wrote: Information is exchanged in communities. All clinical information belongs to the healthcare domain. When clinical concept models (Archetypes) are expressed using an Open International Standard like the CEN/tc251 Archetypes, both the Archetype expression and the constituting clinical concept models are not owned in a commercial sense. Certainly most of us would like that to be true. I was just wondering aloud whether it was true in a strict legal sense. I suspect that it is an issue which requires expert legal advice, and the situation may be subtely different in each country due to differences in copyright law. It just seems like a good idea to investigate such issues when adopting a new paradigm for storing and communicating data. Tim C On 8-jan-2006, at 10:17, Tim Churches wrote: If the argument above - that there is a need to permanent cache or archive copies of archetype definitions with the data which relies on them - then all archetype definitions need to be licensed in a manner which permits users to keep permanent copies of them. My (limited) understanding of copyright law is that such rights are not automatically or implicitly granted - thus an explicit license to keep permanent copies of archetype definitions will always be needed on every archetype definition. Furthermore, if an end user wants to transfer his/her data which happens to be stored using an archetype definition for which the copyright is held by someone else (which will usually be the case, since end users will rarely author their own archetype definitions, especially de novo ones), then the archetype definition used to store the end user's data must be licensed in a way that permits the end user to redistribute that archetype definition to third parties, without the need to ask permission from the copyright holder of that archetype definition. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060108/d4c18933/attachment.html
difficulties starting an implementation
Bert, ITS = Implementable Technology Specification. It is an HL7 specific term. It is the process that translates an hierargical message specification of a domain information model into: Edifact, HL7v2, XML (HL7v3), or Java formats. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 13-jan-2006, at 17:53, Bert Verhees wrote: While reading the docs, I stumble on the acronym ITSs. It may not be that important, but I want to know, what does it mean, I searched on www.acronyms.ch and found: Incompatible Time-sharing System Can someone tell me what it really means, thank you regards Bert Verhees -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060113/865139bb/attachment.html
what is the use of the reference model?
Dear Rodrigo, The Reference Model defines a generic model of any document. And is mapped onto (into) the persistence layer. Archetypes are constraints on the Reference Model but are formed using its own meta-model. Your possibility number 1 is not correct. Possibility 2 is correct. Real data is 'validated' (better: defined) using the Archetype (the constraints) And the archetypes are validated (defined) using the archetype meta- model. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 3-jul-2006, at 20:54, Rodrigo Filgueira wrote: I've been going round in circles about this question all weekend, and have two ideas. 1. It's basic and most important use is to provide reference to check the correctness of the arquetypes. 2. It is needed for some types of persistence design Why am I asking myself this? because once assertions are implemented, all that may be needed for validating real data may be included in archetypes, can't it? am I missing something? thank you -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060703/e567fd7e/attachment.html
Pathology numeric values not supported in DV_Quantity
Thomas, I agree it is very common. But when 5 is reported in essence it means that it is an exception. It is not a precise result. It does not mean that it is less than 5 only. It means that something of an exceptional state in in order. It could be zero, it could be 4.999.. And anything in between but not an exact figure like x=5.1 units of a kind. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 1-mrt-2006, at 14:10, Thomas Beale wrote: Gerard's point about 5 etc being an exception is not quite right - it's very common; -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060301/afb34099/attachment.html
Pathology numeric values not supported in DV_Quantity
Hi, A few words from a non-techie. Quantity means that what is the resulting figure expressing a quantity. Hb: 8.5 mmol/L A property of the Hb measurement can be an uncertainty. This is not an uncertainty of the figure 8.5, but of the Hb measurement where 8.5 is the correct resulting number and mmol/L the code for the units. There can be the question that the reported 8.5 really is 8.5 with/ without roundoff error. Only roundoff could be added to DV-QUANTITY as an added extra property, I think. Uncertainty is added information that the uncertainty of the measurement is plus or minus something according to a specified (or implied) distribution type. In my view uncertainty is the property of the measurement i.e. the specific archetype/template that will express the number This uncertainty will be expressed in an archetype using attributes using DV-QUANTITY expressing the uncertainty as limits and a distribution type term (with a default gaussian distribution?) Gerard Freriks -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 17-mrt-2006, at 12:42, Thomas Beale wrote: The real question is: what is the type origin of data that need to represented in the more sophisticated way that we are now suggesting? Is it a different category of data? Should be leave the current DV_QUANTITY as is and add a new subtype? Or is it that we should consider a quantity with a 95% T-distribution confidence interval as a pretty normal thing? Should we then start considering the simple idea of a symmetric accuracy range (+/- xxx) as really just one specific type of a confidence interval (it might translate to something like 98% on a normal curve). In other words, should we generalise he accuracy notion into a confidence interval notion? -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060317/034709f7/attachment.html
Pathology numeric values not supported in DV_Quantity
Thomas, In a data type like DV - in my mind- only flags can be raised that indicate the technicalities of that number. And that means round off error with which it is reported. All other flags are at the archetype level. Null-Flavors belong there. It is all at the semantic level, the knowlegde level. And not the numeric interpretation level. Gerard -- CEN/tc251 Convenor -- Gerard Freriks, MD convenor CEN/tc251 WG1 TNO ICT Brassersplein 2 Delft T: +31 15 2857105 M: +31 6 54792800 On 21-mrt-2006, at 17:34, Thomas Beale wrote: Sam Heard wrote: It is a flag that says the value is very uncertain - accuracy is not known - how do we say this - or a quality factor makes the reading very uncertain. I just want to be able to see how we express when accuracy is poor but not quantifiable. Sam doesn't it mean that the value is completely useless, and that instead, a null-flavour flag should be set in the Element, and no data value be recorded at all? - thomas
Pathology numeric values not supported in DV_Quantity
Hi, xx or yy What does it mean? To my mind it semantically means a state of exception. Meaning not only that the measurement is xx or yy but that it is unmeasurable. If this reasoning is true than each archetype with a measurement needs an exception attribute. In general this will be true in many more circumstances. Each possible statement (data item and/or archetype) can have a few states: requested/expected- unrequested/not expected (eg expected is TSH measurement but unrequested and unexpected the response is TSH2000 as an indication of exception) As exception there are at least two possibilities: known-unknown. (eg RR 120/unknown mmHg. TSH was measured and presented but it must not be considered a real result it is in doubt) true-untrue (eg I measured RR 60/80 this measurement I consider untrue, but it was that was was measured. TSH 2000 but is untrue because it was unmeasurable) Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 1-mrt-2006, at 2:41, Sam Heard wrote: Hi everyone, We want to report an issue that has arisen in data processing in Australia. The issue is the somewhat random ability of systems to report a xx or yy range where a quantity is expected - there are still units and still a normal range. This is common with TSH and GFR - but can turn up in unexpected instances - e.g. we had a baby with a HCO3 of 5 mmol/L. This can be dealt with at present by substituting an interval - but it is a bit wierd as there is still a normal range - it kind of works as there is only a lower or upper value of the interval and so this single quantity can carry the normal range. The point is that it is really a point measurement that is outside the range of the measuring device. Also, it means that we will have to have archetypes that allow multiple datatypes for all quantities that could conceivably be measured in this way. The alternative is to consider a DV_QUANTITY_RANGE that inherits from DV_QUANTITY - it still has only one value - but now it has the ability to set this as the upper or lower value - and also whether this number is included or not. The advantage is that there would still be a number to graph and this data type could always be substituted for a DV_QUANTITY (ie without archetyping). I wonder what others think. Cheers, Sam -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. Ltd. Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) Ph: +61 (0)4 1783 8808 Fx: +61 (0)8 8948 0215 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060301/7385b9e6/attachment.html
Antw: Re: [GPCG_TALK] Archetype Maintenance
Dear William, My answer is: The moment clinical concepts as defined by groups of clinicians are proprietary it will be impossible to have any conversation. The moment clinical concepts as defined by groups of clinicians using archetypes it will be impossible to have any semantic interoperability between computer systems. Proprietary archetypes used in computer systems are the same as words for concepts used in daily life in discussions between persons. Since the EHR is about documenting by a healthcare provider in ones own words what has happened, they must be able to use all concepts and words, that express them, used in normal speech. You refer to machine computer system interfaces and that these might be proprietary. Yes they could and will. But when the holy grail is about plug-and-play interoperability then these interfaces (archetypes) must be free to use. In my mind users must pay for the use of the machine and demand completely open system interfaces. Information (entered, stored, retrieved and exchanged) must be freed from any influence by the IT industry. Information must be owned and controlled by the users. Information must never be expressed as code in software. Information must never be exchanged in proprietary ways. Without this, generic semantic interoperability between computer systems never will be possible. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 2-mei-2006, at 12:59, Williamtfgoossen at cs.com wrote: In een bericht met de datum 8-1-2006 21:31:57 West-Europa (standaardtijd), schrijft gfrer at luna.nl: Information is exchanged in communities.All clinical information belongs to the healthcare domain. When clinical concept models (Archetypes) are expressed using an Open International Standard like the CEN/tc251 Archetypes, both the Archetype expression and the constituting clinical concept models are not owned in a commercial sense. Gerard Sorry to be late in response, but this comment is only partly true. After having made about 150 archetypes for use in HL7 v3 messages (technical transition being no issue at all, clinical material is), we have encountered several issues. Not all clinical information belongs to the healthcare domain. Many instruments and scales are copyrighted and require a licencing fee. Use in EHR or message is in that case no different from paper versions or dedicated software. This is similar to use of vocab which is or is not copyrighted. Use of CEN / ISO or OpenEHR does not solve this issue, neither does HL7: the clinical content can be owned in commercial sense. It is stil questionable if the model representation of such clinical information e.g. in a HL7 message model, or a CEN / OpenEHR archetype format is not a breach of copyright regulations. Same with terminology: we bind variables and values to terminologies: leaving the decision to the clinician which to use, but to make sure that each element has at least one unique code that is maintained and governed over the centuries. I do agree that once the source material copyrights are sorted out, then the representation in models and storage of clinical data for a patient, or aggregations to group level data from this can be handled open source like, but then we have the consent issue of the patient to exchange information, or to re-use clinical information for managerial or policy reasons. Sincerely yours, Dr. William T.F. Goossen Senior Researcher and Consultant Health and Nursing Informatics Acquest Research, Development and Consulting, Koudekerk aan den Rijn, the Netherlands http://www.acquest.nl/ Adjunct Associate Professor in the College of Nursing, faculty in the Organizations, Systems and Community Health Area of Study, the University of IOWA, Iowa City, Iowa, USA. http://www.nursing.uiowa.edu/facstaff/adjunct.htm Co-chair Patient Care Technical Commission, Health Level Seven, Ann Arbor, MI, USA. http://www.hl7.org Country Representative for the Netherlands in the Special Interest Group Nursing Informatics, IMIA. http://www.infocom.cqu.edu.au/imia-ni/ Member Evaluation Committee International Classification for Nursing Practice, Geneva, ICN. International Council of Nurses http://www.icn.ch/ and http:// www.icn.ch/icnp.htm Associate Professor, Adjunct on the faculty of the School of Nursing, University of Colorado Health Sciences Center, Denver, USA. http://www2.uchsc.edu/son/sonweb.asp Bestuurslid Vereniging voor Medische en Biologische Informatieverwerking http://www.vmbi.nl/ Teacher in health and nursing informatics, MBA Health Management University of Applied Sciences, Osnabr?ck, Germany. http://www.wiso.fh-osnabrueck.de/aktuelle-lehre.html Fellow of the Centre for Health Informatics Research and Development
Antw: Re: [GPCG_TALK] Archetype Maintenance
Bert, The example of SNOMED is a good one. Looking at SNOMED we must ask the question: Are words in a dictionary proprietary? Do we have to pay for the use of these words in our conversations? Of course the answer is: NO. We have to pay for the medium: the book, the CD-ROM, the application. The maintenance of the words used in any language is most often paid for by the State. Language is a free commodity. SNOMED is a Reference Terminology. When local users map their local codes to SNOMED codes only the Terminology Server that does translations using SNOMED needs a licence. In its proposed pricing scheme SNOMED will ask more money from rich countries (millions) and very small amounts (ten-hundred Euro;'s) from poor countries. The are very sensible and indexed to the Gross National Product. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 3-mei-2006, at 11:23, Bert Verhees wrote: You refer to machine computer system interfaces and that these might be proprietary. Yes they could and will. But when the holy grail is about plug-and-play interoperability then these interfaces (archetypes) must be free to use. Gerard, how about SNOMED-tables, they are expensive, and many other terminology-tables? Will there be free replacement for that? This question is also relevant for third world countries, or health-information-systems used by poor organisations, f.e. free health care systems for illegal immigrants in Europe and the USA. They may be able to read messages, because messages probably have beside the code, also the description, but they cannot produce messages, because they will not be able to code their content Thanks Bert -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060503/0032b207/attachment.html
removal of data
Funny? After many years of discussions, after one definitive ISO TR on the topic of the definition, I read that Ed Hammond fears that people will disagree with his views. What you described is : 4.6.2 Definition Integrated Care EHR The Integrated Care EHR (ICEHR) is defined as a repository of information regarding the health status of a subject of care in computer processable form, stored and transmitted securely, and accessible by multiple authorised users. It has a standardised or commonly agreed logical information model which is independent of EHR systems. Its primary purpose is the support of continuing, efficient and quality integrated health care and it contains information which is retrospective, concurrent, and prospective. And something the healthcare provider is using for its own purposes. This is more close to the definition of the basic-generic definition. 4.3.1 Definition The basic?generic definition for the EHR is a repository of information regarding the health status of a subject of care, in computer processable form. So what can be the problem? Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 4-mei-2006, at 15:01, William E Hammond wrote: Mcuh of an opinion of this topic depends on what your view of an EHR is. My view is very specific and focused. The EHR contains the data that is important for the present and future care of the patient. It is legal in a sense that the data should be correct, complete for its purpose, and focused. A clinical warehouse or data repository is where all the data goes and stays. A clinical data warehouse would serve the purpose you identify. A physician treats the patient. It would be interesting to note how such errors are discovered. In my experience, it is frequently the patient and secondly the provider seeing the patient who discovers those errors. If the EHR contains anything and everything without structure and purpose, it becomes too burdensome to use. For example, in the clinical laboratory, it is important to note a series of times - when the specimen was collected, when it arrived at the lab, when it was processed, and when it was reported. The physician taking care of the patient is interested only in the time of the specimen and that the result is reported. I recognize that many will disagree with this position -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060504/3650f5b0/attachment.html
removal of data
The EHR contains what needs to be documented, to be said, in view of the fact that it is the life long record about one patient, isn't it? GF -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 4-mei-2006, at 17:42, William E Hammond wrote: However, in terms of your two references, I still think the wording is open for interpretation of what the EHR contains. I wanted. to be specific. That's what's wrong. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060505/615f1b5a/attachment.html
Archetype conceptual and technical operational are 2 different things
Dear William, CEN/tc251 EN13606 part 2 describes this model that allows us to express it ... unbound to specific technology. Further there is the list: - Clinical concept descriptions: -- Excel sheets, expressed as text in columns, -- CEN/tc251 or openEHR Archetypes, that are formally expressed as constraints on an underlying UML model (part 1 of EN13606), -- HL7 Templates, that are formally expressed as constraints on a derivative of an underlying (Viso) model (the HL7 v3 RIM). At this point in time CEN and HL7 are in the process of harmonising part of of the EN13606 with the work on the Clinical statement. The moment when HL7 starts to deploy the method, described in the HL7 Development Framework in stead of the Message Development Frame work, more intermediate artefacts of HL7 will be expressed in UML. Then HL7 Templates and CEN/openEHR Archetypes can become the same thing. Not only expressing the same thing but being the same thing at the level of the computer. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 5-mei-2006, at 8:05, Williamtfgoossen at cs.com wrote: I look forward to further harmonisation work on archetypes and templates. HL7 template group is currently working on applying ADL / CEN 13606-2 for further work, but given the discussion above, we might need to look for a model that allows us to express it operational, but unbound to specific technology. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060505/7f32b523/attachment.html
[Fwd: Modelling Medication Administration Control]
My answer would be the following. I write it down to make clear I understood the reaction by Sam. -1- An EHR is there to document what has happened -2- An EHR doesn't contain workflow states. That is handled outside the EHR. It is in the EHR-system -3- There will be archetypes that help document a Plan, an Instruction, an Observation. E.g. to Plan for treatment, resulting in an Instruction to give medicines via injection , and the Observation that at the medication/ injection has been administered at a specific point in time by a specific healthcare provider. -4- Each archetype mentioned is almost the same has almost the same structure and will share common internal archetypes. There will be small subtle differences between these archetypes. Plans and Instruction can (but must not be always) less specific than the Observation when something has happened. The Observation is about a specific place, using specific methods, by specific person, at a specific time, etc. The Plan and Instruction can be more vague about the: where, when, what, with what, how, by whom, etc. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 10-mei-2006, at 5:43, Sam Heard wrote: Dear All I will take this slowly. The implementation and modelling processes are different. Modelling: First, each action is a recording which leaves some 'instruction' (which may or may not be recorded) in some state (active, completed, cancelled etc). An Instruction is a recording that calls for some action to take place, and may or may not lead to a recording of this action in the EHR. It can be set to time_out. Otherwise the current state is set by the action record that is generated when someone does what is instructed. As the machine states in which the 'action leaves the instruction' are recorded as part of the action, the archetype of the care pathway steps are in the action archetype. This was not immediately obvious to me - but as soon as you consider that an action can be recorded without an instruction, it is clear that this is where it must be. Also, the instruction is not altered as the actions are being carried out - a distinct advantage which will become clear with more implementation experience. Summary: Actions are things done to patients in response to instructions - in health care these are requests or orders by a provider (generally). Instructions beget actions, and are left in a known state after these actions. Implementation: It seems possible to predetermine all aspects of an action record in the instruction record that generates the action. For example we could say, Give the baby her MMR vaccination or we could say Give the baby her MMR vaccination using a 25G needle in the right thigh laterally at 08:00 on 21/6/06 using batch no: AE43445. It is unlikely but possible. What becomes clear from this is the specification for what could be recorded is pretty much in line with the specification for what could be instructed - the categorical difference is that an instruction will have timing ( times a day after meals), whereas an action will have a time (08:00 on 26/6/06). This is the reason that the archetypes for instructions and actions are sharing a data structure - it is an embedded archetype and the first time we have used this, although the openEHR model has been geared for this from very early days. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060510/a757ecb3/attachment.html
Lifestyle: substance_use archetype
The EHR is about recording observed facts. One of those facts is the use of substances. This means one has to document: - What - What for - How - How much - When - Prescribed by whom, when, where - Dispensed by whom, when, where - Administered by whom, when, where - Used when - ... Irrespective of a regular drug, herbal tea, food additive, smog, self medicated, prescribed, or taken by an involuntary action one always want to record the same things. Isn't it? So why not a generic Archetypes: Observation: Substance Use Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 10-mei-2006, at 15:53, Bill Walton wrote: Hi Karsten, Karsten Hilbert wrote: Recording substance use is more intended to record a *fact* about the lifestyle of an individual rather than an *intent to treat* as with prescription drugs. There's a fine line as always: herbal teas, OTC drugs etc may or may not have been intended to be treatment by the provider. However, disambiguating such in a given case is at the discreetion of the provider/patient in question. OpenEHR needs to provide facilities for both. It seems to me that 1) we want to provide a mechanism for recording _all_ substances used, and 2) for each, we want to record who 'prescribed' it. Patients intend to treat when they ingest herbal teas, OTC drugs, etc.. While I definitely see the value in recording the 'prescriber', I still don't see the value in creating a seperate archetype for 'substances' that are not provider prescribed. In fact, it seems to me to create unnecessary complexity. Example... A patient is undergoing chemotherapy. The patient finds that smoking marijuana helps control the nausea. If the patient lives in California their physician can prescribe the use of marijuana. It they live in Texas, its use cannot be prescribed. Another example... A patient wants to quit smoking cigarettes. The physician prescribes Nicorette gum. Then the FDA approves Nicorette for OTC sale. What would be the information value of recording this information with different archetypes? What would seperate archetypes allow me to do that I couldn't do as easily with a single archetype with a 'prescriber' attribute that could accomodate a value of 'self'? Thanks, Bill -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060510/7eb8a429/attachment.html
CEN 13606
Dear Andrew, There is a very substantial overlap between OpenEHR and EN13606. Both technically and personally. But there are differences. EN13606 EHRcom is the result of an European/Australian consensus process and can not be equated with OpenEHR. EN13606 can be used to map to legacy systems and interact with OpenEHR conformant systems. OpenEHR is a much richer specification that can be used to produce an EHR-system with real plug-and-play semantic interoperability. Within the framework of OpenEHR it is (will be) possible to use the CEN EHRcom extract. For all practical purposes I consider OpenEHR as a specific implementation specification of EN13606 with some important additional features. My advice is to use OpenEHR as an implementable specification and make and use archetypes derived from OpenEHR. The status of EN13606 EHRcom is that the parts 1,2,3 and 4 are stable. Part 1 is final and will be published soon, I expect. Parts 2,3 and 4 will be voted on soon and published next year. It is expected that soon ISO will adopt these standards as well. Your technical comments I will refer to Dipak Kalra the task force leader. ADL and part 2 of the EN13606 are identical. Gerard Freriks -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 3-nov-2006, at 10:27, Andrew Patterson wrote: Apologies that this is perhaps not the right forum, but I sense there is a fair crossover between the CEN and openehr communities so I thought this might reach the right ears.. I have been perusing the draft cen 13606-1 specification in my exploration of all things openehr related (given the large overlap in ideas.. two level modelling etc). I was wondering if anyone had any ADL archetypes based on the 13606-1 reference model? I am going to hand craft some as an experiment but would love some that are more clinically valid than my idle musings.. On related notes - I do not normally have any access to cen materials and am completely in the dark as to the whole cen standards process, but I take it that 13606-1 is in draft mode, awaiting a vote on acceptance? From my brief reading, it seems not ready for 'prime time'.. two that immediately came to my attention were the ED support type that has a compulsory language attribute (which means what for a photo?) and URI reference? Maybe the UML diagram is wrong or something but it seems to indicate that both of them compulsory, when surely they have to be optional attributes? (I have just read it again, and in their defence, it does say they are waiting for a new datatypes standard to be published so perhaps they have not looked too much at this area).. But even the examples seem confused.. annex C has an 'informative' sample ehr_system.extension = Whittington ehr_system.assigningAuthorityName = NHS ehr_system.valid_time = 1/1/1990 - 1/1/3000 ehr_system.root.oid = 9876543211 Why would any health standard be promoting an example using 'magic' dates to indicate infinite time ranges?? Surely these are open ended intervals rather than actually statements that this ehr_system is going to cease to be valid in the year 3000? I know its just a sample, but if the sample doesn't show the proper techniques, what chance does any programmer reading the spec have to do it correctly.. I also am under the impression that 13606-2 will be an effort to standardise the expression of archetypes? Is ADL in its current form a contender for that standard? How far along is the standards process and are there any avenues to review the work (for non-europeans)? Andrew ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061103/d30d6990/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN 13606
see below. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 3-nov-2006, at 14:02, Andrew Patterson wrote: So 13606 EHRcom is very much a go-between format - something that can be used to transfer clinical data between systems, but not something around which you would build an actual running system i.e. a system sitting in a GP's office? Is that the correct thinking? Yes, this is how I understand things. Your technical comments I will refer to Dipak Kalra the task force leader. ADL and part 2 of the EN13606 are identical. How does the openehr governance and CEN process mesh? At the moment, if we find a typo in the ADL spec, we mail Thomas and he fixes it (I know there is an actual formal openEHR process but for simple changes, that is what is boils down to :). When it becomes an ISO standard, do changes to the openEHR ADL spec automatically transfer across into the ISO standard? Is there any chance in a divergence between the languages? For quite some time I'm of the opinion that conformance testing of standards is useless. We need to test conformance against an implementable specification. In general the standard will be the most generic stable point of reference. But in reality we all know that reality and experience evolve faster than any standardisation organisation is able to cope with. For all practical purposes OpenEHR is the fast track, quick response, organisation taking care of a version of an implementable specification. In the case of CEN13606 part 1 conformance testing should be done using the OpenEHR specification (the CEN Extract part) In the case of CEN13606 part 2 conformance testing should be done using a designated version of the OpenEHR ADL specification. It will be up to OpenEHR, the user community and possibly others (like governments) to decide when to correct, amend and update the standards. Andrew ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061103/e9e5d78d/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
HL7 templates/archetypes
Dear Dana, Asking the question on the OpenEHR list is answering it. In my view only CEN/tc251, openEHR and ISO any time soon have the answer: Use OpenEHR and the CEN and ISO standard. This means the CEN part one standard is modelling any document or fragment there off. This means CEN part two defining ADL. OpenEHR is an implementation plus of the CEN/ISO standard for the EHR. And provides the Archetype Editor to produce archetypes that can represent clinical information Models. Both part one and two enable plug-and-play semantic interoperability. HL7 has nothing that is coming close to something usefull and implementable. The HL7 RIM has some known problems. The message Development Method has short comings that make it less than optimal for scalability. Besides EN13606 will become an European standard and an International worldwide standard via ISO in addition. Is there any real choice? Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 15-okt-2006, at 19:13, Dana Prochazkova wrote: Hi, I'm writing my diploma thesis at the Vienna Medical University and I have a question concerning the HL7 templates/archetypes. I'm aware that this sites are related to the openEHR but maybe somebody can answer the following question: Which model (RIM, R-MIM, ...) and which formalism (ADL, OCL, OWL, ...) should be used for the description and creation of the entry-level templates? Thanks for a brief answer! Best regards Dana Prochazkova -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061015/5d7ef537/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
AW: HL7 templates/archetypes
Dear Dana, Why would you like to do that? Theoretically it might be possible to map computationally constraints imposed on one model to others imposed on an other, where both ways express the same clinical model. But I doubt that this can be done. So far only humans can make the translation since only us humans have an internal ontology, an internal knowledge of the clinical world, that makes this possible. As far as I can see it, the CEN/tc251 EN13606 part 1 is a model of any document. The HL7v3 RIM is a linguistic model of any possible statement of fact. Both are not the same. For instance the HL7v3 Mood attribute in the HL7v3 RIM will map onto a specific type of Archetype. Types of Archetypes are based on a model of clinical treatment: Observation, Evaluation, Instruction and Action. And types of Archetypes are not attributes of the Reference Model, they are different beasts. In addition the RIM has all kinds of attributes CEN does not need. The combinatorial possibilities of all the structural attributes go into the billions. This amount of nuance exceeds the possibilities of computation and comprehension. HL7v3 RIM has not defined and used the major RIM classes in a rigourous way, as was shown during a discussion on a HL7 list with the subject: Why is a document an Act. What is your reason/driver to try the impossible? What might be possible in a way, is to transform from CEN to HL7 and back again when a R-MIM is used that is an agreed mapping of the CEN/ tc251 EN13606 part 1 Reference Model using the RIM. Part 5 of the CEN EN13606 standard will contain such an R-MIM, is the expectation. Why is such an undertaking of mapping between EN13606 and HL7v3 interesting? Only CEN/tc251 EN13606 makes plug-and-play semantic interoperability possible. Only EN13606 will enable that conformant systems can be searched using the same query and expose any information stored in that system in an uniform interpretable way enabling better easier clinical decision support. Greetings, Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 15-okt-2006, at 22:30, Dana Prochazkova wrote: Dear Gerard, thanks for your answer. In my work I try to map openEHR and CEN archetypes to the HL7 model. For this purpose I need the information about how to do that. Dana -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061015/4caca739/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN and HL7 methods and archetypes
Dear William, You write: I believe it is very hard to accept the dogmatic approach of Gerard Freriks once again :-( My simple dictionary reads: dogma |?d?gm?| |?d?gm?| |?d?gm?| noun a principle or set of principles laid down by an authority as incontrovertibly true : the Christian dogma of the Trinity | the rejection of political dogma. ORIGIN mid 16th cent.: via late Latin from Greek dogma ?opinion,? from dokein ?seem good, think.? By the way, I like the original old meaning of Dogma better. When we can agree on the modern meaning of Dogma, I will not object either:-) You find it hard to accept that something is 'inconvertibly true', is the way I interpret your quoted sentence. When you will choose to disagree with me then you must provide arguments and try to convert me and the readers. My list of positions and arguments, open for debate and written or presented or discussed several times at various occasions, are: Harmonisation: CEN and HL7 Harmonisation between CEN EN13606 EHRcom and HL7v2 is not taking place. Harmonisation between CEN EN13606 plus its Archetypes and HL7v3 message artefacts is not possible. Harmonisation between CEN and HL7 on the level of Archetypes as performed by humans using the OpenEHR Archetype Editor Tool (and therefor EHRcom part 2) is possible. This is very much needed and taking place. Harmonisation between CEN EN13606 EHRcom and HL7v3 work on the Clinical Statement might become possible and has to be proven. It depends on the way this HL7 Clinical statement is expressed; e.g. what Reference Model will be used. CEN/tc251 EN13606 EHRcom and HL7v3 mappings In general, mappings are possible, only, when both worlds share one or more meta-models that guide the transformation/mapping. At the Archetype level, when archetypes are presented to humans, only humans are able to translate in the absence of a formal complete and accepted Ontology. (This situation is what you write in your last sentence. Humans easily are able to translate clinical models expressed via HL7v3 to CEN Archetypes and vice versa) At the level of Archetypes, as expressed by a formalism describing constraints on a Reference Model, transformation is possible when both Reference Models can be mapped. Part 1 of the CEN/tc251 EN13606 is not the same model as the HL7v3 RIM. A mapping between these two is not possible. They are certainly NOT the same. Only a computational mapping might perhaps be possible with some effort between Archetypes on the basis of CEN/tc251 EN13606 part 1 and a HL7 R-MIM expressing EN 13606 part 1. By the nature of the process these meta-models can be mapped, partially. Extra models are needed to deal with all possible mappings of structural HL7v3 vocabularies and elements in the CEN Reference Model (part 1) and types of CEN archetypes (part 3) Requirements based standards CEN/tc251 EHRcom (and OpenEHR) is the only EHR related standard, I know, that is meticulously based on a well researched set of requirements for the EHR as published by ISO. Proof of Concept: working software CEN/tc251 EN13606 EHRcom is based on more than 15 years of research in Europe and Australia. Various Proof of Concept studies have been performed. The most recent one is OpenEHR, its open source specifications and published functional software. Plus the proprietary software produced by OceanInformatics from Australia based on CEN/tc251 EN13606 EHRcom and OpenEHR. Scalability Message paradigm versus the Archetype (Two Level Model Paradigm) Any solution derived from the RIM and expressed as a message using the HL7v3 MDF method will NEVER scale. Since each vendor has to write specific software for each artefact and version of it. Each clinical domain will consist of many messages. There are many clinical domains. Any solution based on the CEN/tc251 EN13606 is scalable by the fact that only one schema based on part 1 has to be implemented by the vendor, ever. Any CEN archetype or set of archetypes assembled in a Template can be read, stored, retrieved, presented and exchanged without the need to write any software by the vendor. Therefor EN13606 and OpenEHR provide build-in scalability. Decision support Systems that are conformant to EN13606 EHRcom have as an additional feature that software providing decision support is able to query ALL the data stored since all data in conformant systems is presented using one uniform method without any extra programming. Plug-and-play decision support becomes possible. Plug-and-play CEN/tc251 EN13606 EHRcom makes real Plug-and-Play semantic interoperability possible. Status EN13606 EHRcom not only is becoming an European Standard and a National Standard in its Member States, but is on its way to become an International ISO standard as well. Role of European standards European standarisation is subject to various European Directives. European standards play
Antw: Re: AW: HL7 templates/archetypes
William, Since when is it a lie when one states his opinion? Read my other e-mail where I state more opinions and provide some arguments. Read in that e-mail also the fact that CEN/tc251 EN13606 and OpenEHR are based on many years of RD and real implementations. EN13606 EHRcom is factual NOT in its infancy, as you know. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 16-okt-2006, at 8:40, Williamtfgoossen at cs.com wrote: Only CEN/tc251 EN13606 makes plug-and-play semantic interoperability possible. Only EN13606 will enable that conformant systems can be searched using the same query and expose any information stored in that system in an uniform interpretable way enabling better easier clinical decision support. Gerard, are we now in the stage that we have to ly? I agree that both implementations are still in infancy, but there is no way you can substantiate this. William -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061016/9b66ef38/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
[Norton AntiSpam] Re: OpenEHR and Prodigy DSS
Sam, and others, For your information. Slowly I'm preparing an European project for the 7th Framework program around the topic: the EHR. Clinical decision support and a common open source EHR-engine is part of it. Eurorec (the European Institute for the Health Record) might become the main developer and submitter. Lets generate a set of research questions that we can write into the project proposal. Gerard -- private -- Gerard Freriks, arts EuroRec Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 23-okt-2006, at 0:02, Sam Heard wrote: Hello Ian The interaction between openEHR and decision support has been a major design requirement from the mid-1990s. We have used Prodigy as the basis for decisions as it was the most comprehensive at the time. I am interested in the VirtualEHR offered by the openEHR kernel being able to plug-in the decision support modules that the clinician wants to use. You will understand that the kernel is able to query and write to the EHR, and will throw events when archetypes are loaded (the clinician is about to record something) and when they are populated IN MEMORY. This is an extraordinary opportunity for standardisation of decision support in applications. I would be interested in working with others on this approach. The first decision would be to decide how the plug-in might work - within Ocean we use .Net and there are provider patterns that make this relatively straightforward. The open source group are looking at Eclipse for the Java code and I think that this design requirement is the best reason to have the Kernel written in Eclipse. Cheers, Sam Ian McNicoll wrote: Hi, I noticed with interest that one of the older Service Model documents (2003) mentions an interface between the Prodigy DSS and the OpenEHR architecture. The section was blank. Is there any other pertinent information as I am about to start an MSc dissertation looking at exactly this piece of work? Dr Ian McNicoll ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. Ltd. Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) Ph: +61 (0)4 1783 8808 Fx: +61 (0)8 8948 0215 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061023/009d5d95/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
blood film observation archetype
Dear Colleague, Archetypes are clinical concept models. They communicate and express domain information models about clinical concepts. Archetypes are ways to express clinical knowledge on what has to be recorded documenting the provision of healthcare. Archetypes (at this moment) are not designed to deal with clinical knowledge about the interpretation of documented clinical facts. Decision support. Fields in archetypes that are specified are containers to be used for documentation. One type of the family of archetypes is the Observation. One of the possible observations is the Lab-test. For each lab-test the following things will have to be (can be) recorded about the test itself and its results: - name of the test - value/outcome/result - units of measurement - normal values - interpretation - comment -relevance- Each healthcare provider that is using this archetype will be able to record the indicated information about any lab-test. The name of the test plus units of measurement are linked to each other. Result is the number that is the result of a measurement that is recorded and can vary. Normal values are dependent on local circumstances. Each lab has its own normal values for all of the tests they perform. The interpretation of the test result and its normal values are dependent on local arrangements, clinical speciality, and patient related contexts. The comment is additional information that has to be recorded about the test. Thinking about it I foresee the need for a flag indicating that this lab test result is considered relevant or irrelevant by the Observer. The reason for this is: Suppose all fields are filled but the comment field states that the blood was not collected properly. Then all data that is recorded is interpreted as less relevant/reliable but can not (must not) be disregarded fully. Perhaps all Archetypes of the Observation Type need this extra field I call Relevance. To answer your e-mail. I think that the normal value and the interpretation are NOT part of the archetype definition. Within the archetype specification one can not deal with all situations that influence the normal values dependent on local contexts that vary from point in time to point in time, from place to place and from context to context. Normal values have to be provided by the lab. The interpretation has to be provided by the Observer (e.g. the lab or the physician). Or in the case of Clinical decision Support the module that handles this type of clinical knowledge. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 25-okt-2006, at 0:27, Rodrigo Filgueira wrote: We've been running throuh the normal and possible ranges of values for lab tests and found that the archetype I mention in the subject does not state but a bigger than 0 restriction for Haemoglobin, RCC, etc. I decided to take a look because ranges provided to me indicated diferent possible ranges for male and female patients and was wondering how would archetypes model this issue. This is a very similar question to another one I did some time ago regarding normal, abnormal, dangerous, etc. ranges. But in this case my question refers to the possible values the test may return. In order to differentiate male from female ranges assertions would need to be introduced? Or do you believe this is too a matter of decission support? thank you. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061025/d4aeb5ab/attachment.html -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: EHRcom/openEHR the new exciting paradigm
Dear William, One very important point I forgot to make: You wrote: Any discussion in favour of one and against another approach is going back to the trenches of WW1 where we would like to work towards the future. What you write is that any discussion pro or contra a point of view will lead to a kind of war and prevents good results in the future. This line of reasoning is strange for a person active in academic worlds with a PhD thesis in his CV. A discourse pro and contra a point of view is the essence of science because it leads to better understanding of our complex world. This line of reasoning of yours makes me feel uneasy because this way of argumentation is one seen in religious fanatics that don't want any real discussion. With regards, Gerard Freriks -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 15-sep-2006, at 19:08, Williamtfgoossen at cs.com wrote: Any discussion in favour of one and against another approach is going back to the trenches of WW1 where we would like to work towards the future. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060916/16b56c63/attachment.html
Antw: Sources of information on HL7 EHR/OpenEHR
Graham, Isn 't is a matter of scope, as the thing we need to have agreement on first? Isn 't is a matter of requirements, as the thing we need to have agreement on second? Will the rest of the harmonisation process follow from that? I think that harmonising two things with substantial different scopes and requirements is impossible. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 19-sep-2006, at 4:30, Grahame Grieve wrote: This will be hard, and painful. And it must involve compromise, so this is when we find out who really values collaboration. And we don't want to take away the real benefits that OpenEHR has in the process (same for HL7) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060919/2204c91f/attachment.html
Normal and other ranges
Hi, I'm not a pathologist. But was a GP. As GP I'm not interested in an arbitrary classification. What is minimally necessary are: the value, the units of measurement and the normal range as used in that lab for that measurement at that time. What is handy (optional) and only for signalling a human reader, and NOT for computer semantic processing, are: a Flag that a value is out of range, and a comment/advice/interpretation provided by the lab. Value is not always a series of digits. It can be an ordinal. It can be text. Gerard -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 On 20-sep-2006, at 0:27, Heath Frankel wrote: So, it appears that we have no pathologists on the list to comment on the standardisation of these codes. I guess all I can suggest is that these are standard codes as per the HL7 V2.x standard but the interpretation of using them is unlikely to be but it is just that we are looking the capture and not loose in the translation from HL7 message to openEHR. Having said that, in Australia it is common practice by labs to use three levels of abnormality (i.e. HHH LLL(. Would an alternate approach be to include an additional element in the Archetype to store this abnormality flag rather than including it in the DV_ORDERED? -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060920/d4e495da/attachment.html
Specialisation do we need archetype specialisations
Dear all, As an other layman my two cents to the discussion. Specialisation Since archetypes express what can be maximally documented about a topic, and because in the Template the archetype can be constrained maximally to fit the local context at that point in time, I think there is almost no need for specialization. In the example given below. It is clear that both BW and BWB example at the same time Body weight and Body weight at the time of birth can be generically handled and do not need specialization. Body weight change is always relative to an other measurement. I see no reason why these aspects of what can be documented around the topic Body weight can not be in the same archetype. At Template design time the appropriate attributes will be selected or deselected. A possible example There is the generic Weight archetype as an Observation. Expressing all that can be documented about any weight observation. And then we define a specific specialized one for Body weight or Organ weight or thumb weight or compound weight, etc, etc, etc I do not think this is the way to go. The world is large and to many specialization's will be produced. I think it is wrong to have an archetype called Body weight. We only need ONE about all aspects of WEIGHT of anything. My line of thinking is: When all that can be documented about a concept is defined in an Archetype and the concept is weight than the topic is about weight measurement of anything. Within the archetype there must be an attribute what the focus of the concept is. So we must be able to indicate in an archetype attribute whether this a person or a thing. It must be possible to indicate what is observed. At the Template level I see specialized Sections be constructed containing generic archetypes. Archetypes that define precisely in the context of measurements in newborns and grownups what will be documented about weights. I'm curious to learn what are the real use cases for Archetype specialization. I see the need for specialization in the Template phase under control of the knowledge domain. In the meantime the tools must be able to support specialization. Gerard -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On Dec 14, 2007, at 8:39 AM, Daniel Karlsson wrote: Dear Everyone, actually I was going to re-state the questions to the technical list, but will cross post it to the clincial (will I be banned???). For the clinical list read the original message below: For the technical list, I would still like to have the details of specialisation laid out. Are constraints inherited and thus implicit in the specialised archetypes' definitions? Then, in the BW/BWB example, are also the weight gain/loss inherited (which according to my layman understanding is not very sensible for birth weight). Clear semantics of specialisation would be necessary to bring further any discussion on support from tools in this area. /Daniel Daniel Karlsson, PhD Department of Biomedical Engineering/Medical Informatics Link?pings universitet SE-58185 Link?ping Sweden -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071214/93e9cf9a/attachment.html
Archetype production: Types of Archetypes
A few thoughts about Types of Archetypes Archetypes are constraints on an UML model. Archetypes define what can be documented about a topic. Templates are Archetypes. Archetypes are not Templates because Templates are the aggregated archetypes, collected and further constrained to suit a specific business context. In order to reduce possibilities for confusion we need to become more clear what we mean. Semantic interoperability and confusing meanings of things do not go well together. Types of Archetypes Templates: Archetypes suiting the needs of a specific business case/context, constraining parts of the EN13606 or OpenEHR Reference Model, the Folder class, the Composition class and Section Class, plus, in addition, constrain included Entry Archetypes that are parts of the Sections. Entry Archetypes: Archetypes that in general collect what can be documented in general about a health concept using Cluster Proto-Archetypes and Element Proto-Archetypes. There are: Demographic, Observation, Evaluation, Instruction and Action Entry Archetypes. [Question: What type is a Patient Mandate Archetype?] Cluster Proto-Archetype: Archetypes that in general collect/unite two or more elementary archetypes Elementary Proto-Archetype: Archetype that defines one aspect of an Entry Archetype Re-Use Re-use will take place at the Template Level (ieTypes of documents in other documents, types of sections in other sections, etc) All these reflect business needs Re-use will take place at the Template Level by using Entry Archetypes. Reflecting interoperability needs Re-use will take place within the Entry Archetype by means of generic Proto-Archetypes. Reflecting interoperability needs. Gerard -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071214/8b33b8b6/attachment.html
Archetype lists and possible archetypes
Sam, About restricting slots. It must not be an on/off type of restriction. Is it possible to have 'types of archetypes'? And then. What 'types' are needed? Isn't there a need for an 'Archetype ontology' that helps provide 'types of archetypes'? Gerard -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On 21-feb-2007, at 15:51, Sam Heard wrote: SECTION: Vital Signs It is clear that vital signs section should only contain a limited set of observations - although this might change over many years with the introduction of Oxygen sats for example. Even then, perhaps a specialisation of the archetype is better - or a new one. So here the slot may allow temperature, pulse, blood pressure, respirations and O2 sats. So we may need to say here that no other archetypes are allowed. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070221/f184c2d3/attachment.html -- next part -- ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
CEN meeting and data types
Sam, It would be helpful to provide (more) arguments for your opinion. Gerard -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On 22-feb-2007, at 0:42, Sam Heard wrote: Dear All I have been at the CEN working group meetings representing Standards Australia. It is clear to me that CEN needs to take on the openEHR data types in order to progress quickly. The ISO data types are likely to be appropriate for the HL7 environment and will map to openEHR - but the openEHR data types are ready for archetypes and the cluster element (leaf node) architecture. You can have a look at the ISO data type proposal likely to come through HL7 soon at: http://informatics.mayo.edu/wiki/index.php/ISO_Datatypes user name: wiki password: wikiwiki It will be helpful to make your views known on this list. Cheers, Sam -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. Ltd. Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) Ph: +61 (0)4 1783 8808 Fx: +61 (0)8 8948 0215 ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070222/d3ef26c7/attachment.html -- next part -- ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
CEN meeting and data types
Thomas, I agree with you that in the case CEN (13606) adopts the OpenEHR data types they know that it is proven technology. Just now, when any moment CEN/tc251 EN13606 will get published, we dearly need proven data types to implement it. In the case that CEN will make the choice for OpenEHR, my remaining questions are: What harm is done? How can CEN/tc251 EN13606 be aligned, some years from now, with the forthcoming ISO data type standard? Can it be aligned? Or can't it? Gerard -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On 22-feb-2007, at 11:27, Thomas Beale wrote: Grahame Grieve wrote: hey Sam I'll bite ;-) but the openEHR data types are ready for archetypes and the cluster element (leaf node) architecture. it you want, we can go round and round on semantic issues. Always a pleasure ;-). But is there anything specific that makes you think that it would be inappropriate or unwise to use the iso datatypes in the document with 13606? (so not including general issues) I guess it depends on what CEN wants to achieve, and also what the implementation state and intention of the ISO types is. Possibilities I see: * Let's say that the ISO types provide a set of types whose purpose is to facilitate data type conversion between HL7 HL7-like (e.g. various flavours of v2, v3 etc), openEHR, others (UN-cefact? ASTM? etc). Then the kind of implementations will be limited to XML conversion. * On the other hand, if they were used as real data types, say in CEN, then there is now the job of implementing them in all the major technologies and testing them. Plus they need to be checked for use with archetypes. * If CEN used the openEHR data types, they get something implemented in Java, C#, Eiffel, XSD (others?), that are heavily debugged and in production use now, and for which the constraint semantics and syntax are already known and tested in ADL. This includes constraint types for String (C_STRING), Integer (C_INTEGER), Date (C_DATE)..plus specialist constrainer types for DV_ORDINAL (C_DV_ORDINAL), DV_QUANITTY (C_DV_QUANTTY) and CODE_PHRASE (C_CODE_PHRASE). These have all been tested and are known to work, and numerous archetypes have used them. Also, the openEHR data types are founded on existing standard data types (ISO11404), and assume the standard semantics for all the usual built-in things (String, Integer, Boolean, Array, List,...) plus the ISO8601 date/time types (Date, Time, etc) Now, since CEN is an archetype-enabled standard, it might make sense to use data types that are known to work in software and known to work for archetypes. So one question is: what is the intended use of the new ISO date types (conversion, or to be the 'real thing')? Secondly, how will CEN EN13606 be validated with a new set of data types? - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070222/34fb2ebf/attachment.html -- next part -- ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
Fwd: discussion item: carrying repeating information from query responses in the control act wrapper
Dear colleagues, Below an e-mail from the HL7 list. The problem is clear. Performing a query to several systems provides a lot of repetitive information. One query for all the medication about one patient provides for each prescription all the relevant data and all its contexts. So a lot of repetition data about the patient, the medication, pharmacy details, etc, etc. In the realm of HL7 messages this creates a lot overhead. How are things like these handled in OpenEHR space? Is there a query spec that makes the distinction between what info is asked and how it should be presented in what specific format? Gerard -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 Begin forwarded message: From: Rene Spronk (Ringholm) rene.spronk at ringholm.com Date: 24 februari 2007 12:56:34 GMT+01:00 To: Tom de Jong tom at tdejong.demon.nl Cc: mnm at lists.hl7.org, inm at lists.hl7.org, 'Michael Tan' tan at nictiz.nl Subject: Re: discussion item: carrying repeating information from query responses in the control act wrapper Reply-To: Rene Spronk (Ringholm) rene.spronk at ringholm.com Tom, Good question - similar to ones raised by the NHS. Assuming no changes to the current query response mechanism: a. one could create a query response model that only contains the patient Id, or even omits it entirely [because the context is known to both querying as well as responding system], this would remove any duplication. b. it has to be said though, that the simple fact that all responses contain the same national patient ID doesn't mean that all other demographics data as known in the various systems is the same. As such generating a joint of that data (and convey it outside of the payload: in a controlAct or even in an attachment) will be problematic. Each of these ?items? is messaged using a separate subject element in the query response. That's strictly take not necessary - one could have multiple relationships within a single payload, a payload that has only one Patient class. Note that the Dutch use-case includes the use of an orchestration server which groups query-responses from various applications. This is new territory for HL7 so it doesn't describe nor contain any expected behaviour of such a server. The above doesn't really answer any of your questions, it just describes options.. so please comment if you have other ideas.. TTYL, -Rene Tom de Jong wrote: Dear all, I?d like to raise an issue for open discussion that comes up time and again when dealing with queries, especially when these queries have the potential for a large number of ?hits? in the query response. I?ll illustrate with an example: I query a central drug information database that contains data about medication dispenses performed at different pharmacies. My query parameter is a national patient identifier. The response message contains a full history of all dispenses for this patient, which is a list of hundreds of items. Each of these ?items? is messaged using a separate subject element in the query response. The message model for this payload contains an R_Patient CMET, so that full patient information can be associated with each dispense. But since my query parameter was a patient identifier, the patient information will in fact be identical in each of the hundreds of subject elements in the query response. This results in considerable overhead in the response message. Of course one could argue that *only the patient identifier* should suffice to confirm the fact that the dispense records match with the query parameter, but if the message model allows for the possibility of including full patient information, any query filler system can choose to send it anyway. Another option that has been suggested in implementations is to have *full patient information in the first dispense record* (i.e. the first repeat of the subject in the query response), but only a patient ID in all the others. This can also not be disallowed, but is clearly a quirky solution to a very practical issue. A more fundamental solution would be to move all the patient information up one level and message this as part of the control act wrapper (so outside of the repeating subject elements). Since there?s essentially nothing special about the patient information, this method could also apply to other situations where an *association with the focal class repeats identically in all records of a query response*. The key ingredient from a semantics viewpoint of course is that there would need to be *context conduction* through the control
