ADL to XML Schema
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. 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. well, this has been stated for a long time, but there is little evidence of it happening. A recent post from the HL7 templates list indicates the current state of play...in short they using something called MIF to do templates, which are approximately the same as archetypes. But it is complicated in HL7 because there are two ways to create any model of a clinical concept: using a template (presuming they finish defining what they think a template is) and using an RMIM - a message model. CEN doesn't need archetypes based on its own model, although not everyone in the working realises this yet. However, I had a recent discussion with Dr Gunnar Klein (chair of TC/251) and he now understands the reason why basing archetypes literally on EN13606 does not make a lot of sense. The documents you mention are indeed somewhat confusing as currenly worded and have to be changed; I will be recommending changes at the next CEN meeting. One question arises are these EN13606 archetypes different from OPENEHR archetypes?. Could you show some examples of clinical concepts that can not be expressed as archetypes derived from EN13606-1 reference model?. Surepractically every archetype we have built. Have a look at the archetypes either using the adl-workbench or jsut on the web - see http://www.openehr.org/repositories/archetype-dev/latest/index.html. Consider the apgar archetype at http://www.openehr.org/repositories/archetype-dev/latest/adl/archetypes/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.apgar.v1.html - you will see it references classes OBSERVATION, HISTORY, EVENT, and LIST, and particular attributes, e.g. OBSERVATION has data, state and protocol (see e.g. blood pressure for example use of these). You can't write any of this using the CEN model because it just doesn't have any of the classes I just mentioned. Instead, you can only write ENTRY, CLUSTER and ELEMENT, which is too limited. CEN is designed to carry data that has already been archetyped, not to be a model on which archetypes are based. thanks in advance --- HL7 templates list post - Lloyd McKenzie wrote: Hi John, The internal format of all HL7 v3 content is MIF. It is used for persistence, exhange, as well as for definition of what's possible. The MIF also acts as a UML profile expressing what pieces of UML HL7 permits and what stereotypes we require. The MIF requires that all 'custom' constraints be expressed as OCL, though alternate formal (e.g. Schematron) or free text representations are also supported. (Obviously we're coming up short on OCL representations at present.) Thus, to a certain extent, the statement of UML + OCL is accurate. We just need to make clear that the UML being referred to is the MIF LIM stereotype. Also, the format for registration should be MIF XML to allow for easy validation and checking against other models (e.g. RIM, datatypesn etc.) -Original Message- From: john.si...@philips.com Date: Thu, 3 Mar 2005 11:01:17 To:Mkfrad at aol.com Cc:lloyd at lmckenzie.com, owner-templates at lists.hl7.org, templates at lists.hl7.org Subject: Re: Comments on draft document As an 'outside' observer to all of these discussions there seems to be a core issue of disagreement and one which I share.That is, WHAT is the ITS and what is the 'official' HL7V3 representation of a model - I don't care if it a RIM, D-MIM or Any-MIM, template, CMET. Some contends it's the MIF and others contend it's UML (maybe with OCL) and the MIF is an interchange for the model (it's name suggests it is a interchange format NOT the model itself)! The other problem that seems to crop up is the resistance to use any previously defined mechanism to describe the logic or mathematical constraints on the model itself.When OCL is mentioned it's 'tossed' as an ITS rather than being viewed as an existing 'language' to define constraints.Same thing with OWL or ADL.I can't see why we can't separate the notion of using these 'existing languages or formalisms' to help define our constraints? (*) Just because we choose to use one of these languages for definitions doesn't IMPLY that the specific artifact has to be rendered or, for that matter, even stored in that format; it is used as a means to convey the concept in a more precise language. We could choose to use formal logic languages, assuming that these wouldn't be viewed as 'ITS'es , e.g. relational algebra or regular
EntityNameParts
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
UNSUBSCRIBE
UNSUBSCRIBE henschke at bigpond.net.au - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
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
Op vrijdag 11 maart 2005 08:37, schreef Gerard Freriks: 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 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
UNSUBSCRIBE
Unsubscribe me from this list bruno.giger at ascaion.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050311/12f5cb74/attachment.html
EntityNameParts
On Fri, Mar 11, 2005 at 10:31:09AM +0100, Bert Verhees wrote: Op donderdag 10 maart 2005 13:48, schreef Karsten Hilbert: There are no fixed patterns for names or naming conventions. There are many societies where there are no 'Family' names at all. Some have Tribe names in lieu, some with father's or village name as 'names' somewhere wedged in the name string. Some with just unique names with nothing else. To add to this confusion you would then have to find sub-components for nick names and aliases. Yes, the whole gamut :-) In GnuMed we deal with it like this: Where do you put initials and how do you qualify them as such so they can be recognized in an automated process. We don't have dedicated initials support. Most of the time (I know no other use) initials are the first character of the first name(s). So we either store them as first names (if we don't know the first name but know the initial) or we do not store them. I do not completely understand why you need to be able to *process* initials ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
Op vrijdag 11 maart 2005 12:34, schreef Karsten Hilbert: On Fri, Mar 11, 2005 at 12:12:03PM +0100, Bert Verhees wrote: I am extracting data from existing systems, and put them in a CEN-structure (this is simplified saying of what I am really doing). I do not want to loose vital information in this process There is one system that stores person-data as - Roepnaam (dutch for call name) Pretty close to German: Rufname :-) - Initials It is necessary that to distinguish as much as possible one person from another, both are known in the extracted data. The extracted data can be used for automated processing, so an automated process needs a qualifier to distinguish as callname from initials. Aha. You don't want to loose information you already have. In GnuMed there are several ways to solve this: a) add initials to firstnames - this loses some information but does not make it wrong This can not be processed automatically b) put initials into firstnames - set the name comment to initials only - if the source system does not have firstnames - loses no information - could be processed but is not clean This makes it impossible for an automated process to know with what it is dealing c) extend the lacking specs - in our case extend the GnuMed schema - in your case add a name part initials and use that Yeah, that is a possibility, but then I am alone, no standard supports this. But that is what I am going to do, I guess Can you precisely say what your initials stand for ? Here in Germany they are *always* the first letter of the first name(s). In other countries, too (US, AU AFAICT). In a name, that is. A sig may consist of initials only - first/last names both included - such as on charts etc. Karsten In that system, initals stands for the first characters of the christiannames, but that said, it depends on what the GP has used the field for. But that was what the interface asked him/her to do -- regards Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
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
EntityNameParts
Can you precisely say what your initials stand for ? Here in Germany they are *always* the first letter of the first name(s). In other countries, too (US, AU AFAICT). In a name, that is. A sig may consist of initials only - first/last names both included - such as on charts etc. In that system, initals stands for the first characters of the christiannames, but that said, it depends on what the GP has used the field for. But that was what the interface asked him/her to do That then means you can do this: - check if there are first names - if yes - check if the initials match - if yes - forget the initials: you can recreate them - if no - store them but don't worry about what they mean because you cannot know what they mean (eg the source system does not provide that information) *see below - if no - assume the initials *are* the first name initials - store them in the firstnames field directly *) Now, of course, one doctor will come up and say But I always used that field to store the stardate equivalent of that patient's grandmother's marriage ! In that case (if you want to keep that information for that doctor) you should postprocess the data exported from his source system and store the data in a new field patient_grandma_marriage_as_stardate in your system. Only half kidding. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
UNSUBSCRIBE
hi, If you have any questions about using this list, please send a message to d.lloyd at openehr.org ( Unsubscribe you from this list !! ) regard's Selon Minal Thakkar mthakkar at siu.edu: Unsubscribe me from this list mthakkar at siu.edu - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
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
[OT] - Any Probs ? [was: Re: UNSUBSCRIBE]
On Fri, Mar 11, 2005 at 11:40:55AM +0100, Bruno Giger wrote: Unsubscribe me from this list bruno.giger at ascaion.com ---end quoted text--- There seems to be a flurry of Unsubscribe requests over the last few days, posted on list. Normal logic dictates, that, the best way to get out of any place is to use the same door you came in through. The web innterface at http://openehr.org and going through the links: 'Community - Membership - Login - Remove Regn' was working fine enough. I tried the 'modify' option, to suspended my mails for a short spell, while on vacation. I faced no problems then. o Is there a problem with the web interface ? o Or is it, that folk are opting for the 'emergency exit' as a primary measure ? Perhaps, bringing 'Membership' and 'Discussion Lists' on the opening page rather than hiding it behind the 'Community' link make things easier. Just a suggestion. Bish - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
Op vrijdag 11 maart 2005 15:53, schreef Gerard Freriks: Extending qualifiers is allowed. See, see, the Convenor of CEN TC251 Wg 1, thanks, thank you very much Gerard, I really appreciate!!!, this quick move. It was within the three days I said I could affort to wait. Next week I will try some more questions. Have a nice weekend. Kind regards Bert Verhees 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 -- 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
EntityNameParts
On Fri, Mar 11, 2005 at 12:34:39PM +0100, Karsten Hilbert wrote: [some snipped] Can you precisely say what your initials stand for ? Here in Germany they are *always* the first letter of the first name(s). In other countries, too (US, AU AFAICT). In a name, that is. A sig may consist of initials only - first/last names both included - such as on charts etc. Karsten, you have driven home the point. Look at the variances in what a simple thing like 'initials' may mean ;-) For OpenEHR to proceed as an international foundation, we need to talk a common language, understood by everybody, the same way. There is a need for the following: o Demographic entities need to be defined by us, and archetyped. o Since this links up with every subsequent entry, this section has to be based on philosophies of the 'HCF' (Highest Common Factor). o All nomenclatures used for such definitions should be culture neutral, and as generic as possible. o Once the 'definitions' are made and accepted, developing the archetypes would become simpler. Things would fall into place one by one. Demographic details are one of the toughest parts of any data base. In a multicultural society like mine, I do know what it means, and realise its importance. As regards 'initials' are concerned look for the word 'initial' on dict.org (the definition of about 5 dictionaries are given). However, perhaps better understood, with the following example: What would you expect, if you ask me to 'initial' a document as having seen. Do you expect 'USM' or 'USMB' ? If I ask you to do the same, I would expect you to place 'KH' and not just 'K'.IOW 'initials' are the first letters of the whole name in order of usage. Some societies use Family name in the beginning, so for them the order may differ in the initials from convention. Just my 2p USM Bish Bangalore - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
UNSUBSCRIBE
UNSUBSCRIBE Westberg at wesmarc.com - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
unsubscribe
unsubscribe - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
