# Why is the editor not opening ADL files? **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2009-03-13 11:58 UTC **Views:** 18 **Replies:** 41 **URL:** https://discourse.openehr.org/t/why-is-the-editor-not-opening-adl-files/13890 --- ## Post #1 by @williamtfgoossen Dear all, I am browsing through the existing archetypes from Ocean, obviously created by the Ocean Archetype Editor given the file name. E.g. openehr-demographic-person.person.draft.adl When I try to open it with the AE, I do get continuously error messages similar to:

Is there anything wrong with the archetypes, or is this an error in the archetype editor. Anyone els experiencing such problems? Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort the Netherlands emails: Results4Care@cs.com williamtfgoossen@cs.com info@results4care.nl phone + 31654614458 fax +3133 2570169 www.results4care.nl Dutch Chamber of Commerce number: 32133713 --- ## Post #2 by @yampeku As far as I know, Ocean archetype editor does not support openEHR demographic archetypes --- ## Post #3 by @ian.mcnicoll Hi William, The current version of the archetype editor does not support Demographics archetypes. These archetypes were created manually in raw Adl. I am working on an update to the Editor to support Demographics archetypes but this is still some weeks away from completion. Ian Dr Ian McNicoll Clinical analyst Ocean Informatics Tel/fax +44(0)141 560 4657 Mobile +44 (0) 775 209 7859 Skype imcnicoll --- ## Post #4 by @williamtfgoossen Thanks! Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort the Netherlands emails: Results4Care@cs.com williamtfgoossen@cs.com info@results4care.nl phone + 31654614458 fax +3133 2570169 www.results4care.nl Dutch Chamber of Commerce number: 32133713 --- ## Post #5 by @Greg_Caulton How many more types of archetypes are we envisioning to support? Hopefully the Java ADL parser does not need to change - a new XML schema does not require a new XM Lparser. --- ## Post #6 by @williamtfgoossen In a message dated 14-3-2009 17:23:18 W. Europe Standard Time, caultonpos@gmail.com writes: > How many more types of archetypes are we envisioning to support? I think the tools need to support ANY archetype that represents valid content in health care. Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort the Netherlands emails: Results4Care@cs.com williamtfgoossen@cs.com info@results4care.nl phone + 31654614458 fax +3133 2570169 www.results4care.nl Dutch Chamber of Commerce number: 32133713 --- ## Post #7 by @system [Williamtfgoossen@cs.com](mailto:Williamtfgoossen@cs.com) schreef: > In a message dated 14-3-2009 17:23:18 W. Europe Standard Time, [caultonpos@gmail.com](mailto:caultonpos@gmail.com) writes: > > > How many more types of archetypes are we envisioning to support? > > I think the tools need to support ANY archetype that represents valid content in health care. An archetype editor should simply support any archetype which represents a valid locatable according to the reference model, plus, it must adapt the other archetype-rules as defined in the reference model, such as header requirements, etc. Bert --- ## Post #8 by @system [Williamtfgoossen@cs.com](mailto:Williamtfgoossen@cs.com) schreef: > In a message dated 14-3-2009 17:23:18 W. Europe Standard Time, [caultonpos@gmail.com](mailto:caultonpos@gmail.com) writes: > > > How many more types of archetypes are we envisioning to support? > > I think the tools need to support ANY archetype that represents valid content in health care. An archetype editor should simply support any archetype which represents a valid locatable according to the reference model, plus, it must adapt the other archetype-rules as defined in the reference model, such as header requirements, etc. That is why I don't understand the trouble with supporting demographic archetypes, it are just locatables, with a few extra characteristics, but that is also the case for composition or other archetypes. It are all just locatables. Maybe some one can explain this. In a few months, I will have more time, I will add the support myself, I even install Windows, if necessary. Maybe I find out by then what I have overlooked all the time. Bert --- ## Post #9 by @Heath_Frankel3 William, When you say "browsing existing archetypes from Ocean", where exactly are you browsing? Heath --- ## Post #10 by @Heath_Frankel3 Bert, The Ocean Archetype Editor was the first Archetype Editor written some 6+ years ago. It was implemented to support only EHR archetypes in a way that these RM types where implemented explicitly within the Editor providing the specific capability for clinicians to easily develop archetypes with minimal knowledge of the RM. Certainly a generic archetype editor would need to support the features you suggest below, but the Ocean Archetype Editor is not a generic Archetype Editor. Even with its limitations known best by Ocean, I think we can all agree that it has served the openEHR community well in bringing the mind shifting concepts of archetypes to a point where the openEHR architecture is in demand internationally. Regards Heath --- ## Post #11 by @williamtfgoossen I got these examples in 2007 from the OpenEHR list. This is the one I was working with Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort the Netherlands emails: Results4Care@cs.com williamtfgoossen@cs.com info@results4care.nl phone + 31654614458 fax +3133 2570169 www.results4care.nl Dutch Chamber of Commerce number: 32133713 [details="(attachments)"] [openehr-demographic-person.person.draft.adl|attachment](upload://lb2PAwXJ1DJMpcvF7zZNzR24guC.adl) (13 KB) [/details] --- ## Post #12 by @system Hi William I think this may have been answered elsewhere. The reference model for this archetype is the openEHR demographic model and it is starting to get some interest. It is still a research work in progress. These archetypes where hand built to illustrate ADL working with another model. There are also some v3 RIM archetypes as well. Cheers, Sam --- ## Post #13 by @system Hi Bert and all The demographic model was proposed a long time ago and is meant to support a demographic service – like a PMI. These archetypes are not in the EHR. The EHR and demographic service can share archetypes like data_structures, clusters and elements and for this reason it is worth aligning them. The Ocean archetype editor was built before ADL and works by using the ADL parser and XML parser. The reference model is hard coded as a class. TO work with another reference model it is necessary at the moment to hard code another class. A generic approach to this is possible and may in time be useable. In the meantime, I just want to be clear that the demographic model archetypes cannot be used in the EHR – they are not relevant there. Cheers, Sam --- ## Post #14 by @system Heath Frankel schreef: > Bert, > > The Ocean Archetype Editor was the first Archetype Editor written some 6+ years ago. It was implemented to support only EHR archetypes in a way that these RM types where implemented explicitly within the Editor providing the specific capability for clinicians to easily develop archetypes with minimal knowledge of the RM. > > Certainly a generic archetype editor would need to support the features you suggest below, but the Ocean Archetype Editor is not a generic Archetype Editor. Even with its limitations known best by Ocean, I think we can all agree that it has served the openEHR community well in bringing the mind shifting concepts of archetypes to a point where the openEHR architecture is in demand internationally. There is no doubt about that it did serve many people. Please do not see my comments as criticism. I was really wondering. Now I read your message, I understand a bit better. I think/understand it was even more work to limit the AE to serve people with minimal knowledge of the RM than to build a generic one. I think, to build a generic AE is not that difficult, and can be done in a few weeks by an experienced programmer. There is a lot of recursively in code possible. The point where things gets a bit more difficult is at the end nodes where datatypes have to be constructed and valided, but then again, there is a lot of example code in Java and VB, and one can profit from the inheritance-schemes of the datatype part of the RM. Live-connection to terminology would maybe be a bit more difficult, but it can be a good tool without that. It would be a nice project to do, not to hard, and very useful. Maybe later, when I have time, I will build one. Bert --- ## Post #15 by @system Sam Heard schreef: > Hi Bert and all > > The demographic model was proposed a long time ago and is meant to support a demographic service – like a PMI. These archetypes are not in the EHR. The EHR and demographic service can share archetypes like data_structures, clusters and elements and for this reason it is worth aligning them. > > The Ocean archetype editor was built before ADL and works by using the ADL parser and XML parser. The reference model is hard coded as a class. TO work with another reference model it is necessary at the moment to hard code another class. A generic approach to this is possible and may in time be useable. Thanks for explaining. In my previous message, (before reading this one), I went already into this subject. It is also clear, in my opinion that Ocean has no obligation at all to build any tool. It cost time and money to do so. And the community must be grateful for what it gets. Me, I am. There work of ocean (and many others) give me a wonderful business opportunity. So, if the community misses demographic archetypes-editor, it is free to build one, which I said, is not to hard for an experienced programmer, and it can be done in almost any programming language, even in a Word-macro, however, it is not the choise I would make. > In the meantime, I just want to be clear that the demographic model archetypes cannot be used in the EHR – they are not relevant there. I don't understand what you mean here. In the EHR-Status is a PartyRef ([http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140537614753_438721_176Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140537614753_438721_176Report.html)) to connect the EHR to a Party (which is a demographic object, and thus need a demographic archetype. But maybe I misunderstand what you say. Bert --- ## Post #16 by @Greg_Caulton I am confused - hopefully you saying that those particular 'older' demographic models are not supported? But there are newer ones right being added to the CKM that conform to the ADL structure the other clinical ADLs use? You are not saying an AQL query for Women over 50 - 70, last mammogram > 2 years cannot be supported because demographics are not relevant? --- ## Post #17 by @thomas.beale Greg Caulton wrote: > I am confused \- hopefully you saying that those particular 'older' > demographic models are not supported? > > But there are newer ones right being added to the CKM that conform to > the ADL structure the other clinical ADLs use? Hi Greg, the new ones, based on ISO 22220, made by Rigoleta Dutra and Sergio Freire in Brazil will replace any of those early ones\. I think they are still messing around with them a bit before putting them on CKM\. Initially, they don't have a GUI editor tool, and have to be edited by hand in ADL \(one of the reasons we took the trouble to make sure ADL was human\-readable\)\. > You are not saying an AQL query for > > Women over 50 \- 70, last mammogram > 2 years > > cannot be supported because demographics are not relevant? it already can, regardless of demographics, because such clinically relevant data as date of birth and sex are recorded in the EHR anyway \- you would not attempt to do a join across EHR and demographic services to answer that query\. Although, if you had a service more oriented to demographics \+ admin events, you could potentially satisfy this query on it; however, in general, clinical queries will refer to a mixture of basic data like age, sex, maybe occupation \(where relevant to health\) etc, as well as the 'hard' clinical data; they would normally be run on an EHR containing this data\. \- thomas beale --- ## Post #18 by @williamtfgoossen Sam, this below - demographics not relevant in the EHR is like the most confusing comment ever I heard from you. About whom are we going to create a EHR then? If it is not possible to have the individuals name, id, birthdate and sex in the EHR (generally named patient demographics), it becomes useless in my vue. Or do I miss a point here? William In a message dated 16-3-2009 8:39:20 W. Europe Standard Time, sam.heard@oceaninformatics.com writes: > In the meantime, I just want to be clear that the demographic model archetypes cannot be used in the EHR – they are not relevant there. > > Cheers, Sam Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort the Netherlands emails: Results4Care@cs.com williamtfgoossen@cs.com info@results4care.nl phone + 31654614458 fax +3133 2570169 www.results4care.nl Dutch Chamber of Commerce number: 32133713 --- ## Post #19 by @Tim_Cook2 Caution; a bit of a rant ahead\.\.\.\. > it already can, regardless of demographics, because such clinically > relevant data as date of birth and sex are recorded in the EHR anyway \- > you would not attempt to do a join across EHR and demographic services > to answer that query\. Although, if you had a service more oriented to > demographics \+ admin events, you could potentially satisfy this query on > it; however, in general, clinical queries will refer to a mixture of > basic data like age, sex, maybe occupation \(where relevant to health\) > etc, as well as the 'hard' clinical data; they would normally be run on > an EHR containing this data\. Maybe I should ask a question first\. Are we building a model JUST for personal healthcare; or for general healthcare? I ask this because I get the impression from Thomas' statement \(and the overall all direction of archetypes\. That the mind set is that healthcare information is ONLY personal\. In fact healthcare involves us and everything around us\. Our living spaces, our working spaces, the people that we come into contact with\. We cannot separate our health events from our environment \(geographical or social\)\. I thought that I was aware of this when I lived in the US, Canada, Sweden and studied in the UK\. However, living and working in a developing country for one year now has made me realize just how industrialized and general practice oriented the archetypes are for openEHR\. I sincerely believe that the RM is in good shape \(okay we \(OSHIP\) plan to bring on some bio\-informaticians and that may change things in the RM just a bit\)\. While as an American I love the ability built into the openEHR model to separate demographics from clinical; in the real \(larger\) world, in many cases, that demographic information is CRUCIAL to healthcare systems to see what is happening in a region\. I was the first one to complain \(to Sergio\) that Rigoleta's archetypes didn't comply with the RM \(I couldn't implement them\)\. I should have been complaining to the ARB that we were not ISO 22220 compliant???? I am as remiss as everyone else in not filing CR's so that these changes can go through the proper channels and be decided and changed\. openEHR has a wonderfully organized change manangement system\. We should all use it\. <my rant for today> Stay tuned for tomorrow's rant on why climate change is evolutionary\. :\-\) Cheers, Tim \.\.\.\.now back to making the Python archetype builder actually build archetype instances\.\.\.\.\.\. --- ## Post #20 by @Greg_Caulton Hmm\. I can see why some groups might want to limit the scope of their applications to EHR pure clinical, research type usage that ONLY had clinically relevant demographic data\. But I don't think OpenEHR as a whole should have that scope limitation\. Nor do I think it does, to date the archetypes have shown to be quite flexible in modeling a variety of data\. If Oceans direction is not to tackle hospital administrative and demographic data which is critical to EMR type applications which run in a live, working system then I totally understand that \- you have limited resources and have already done so very much\. This might explain \(ahem\) the delay in getting demographics online\. But what is more concerning to me is that we have a new set of ADLs that are using a new structure that is not compatible with the current set of editors\. Bert said he might have overlooked something, I never looked in order to overlook \- I took for granted that the ADL structure was already maximally defined and that any demographic or administrative data would fit into this structure\. Having looked at new the new demographics they cover demographics and not general administrative data typical to most HL7 interfaces\. I have not ruled out create the archetypes ourselves but I don't have enough resources today\. Our system can support many coding systems but I would have like to understand if OpenEHR leadership are going to support the broader needs of the community \- and we recognize they need resources to do that \- it cannot fall on Oceans shoulders \- but at the same time if CKM becomes the preferred tool we should organize accordingly\. --- ## Post #21 by @thomas.beale Williamtfgoossen@cs\.com wrote: > Sam, > > this below \- demographics not relevant in the EHR is like the most > confusing comment ever I heard from you\. > > About whom are we going to create a EHR then? If it is not possible to > have the individuals name, id, birthdate and sex in the EHR \(generally > named patient demographics\), it becomes useless in my vue\. > > Or do I miss a point here? Hi William, yes, in fact, what he meant was that the more comprehensive demographic information modelled by the openEHR demographic model is not directly in the EHR, it is in dempgraphic information objects, which would typically be in their own service \- particularly in Europe where legislation largely requires this to be the case\. This does not of course mean that demographic information of clinical significance would not be in the EHR, e\.g\. date of birth, sex, occupation etc\. The archetypes that would model these elements are based on the EHR part of the RM, not the PARTY and related classes from the demographic part of the RM\. \- thomas beale --- ## Post #22 by @pablo Hi, I agree, specially if we think of OpenEHR as a PATIENT CENTRIC specification of an EHR. Cheers, Pablo. --- ## Post #23 by @system Thomas Beale schreef: --- ## Post #24 by @system Hi Greg No – we are not on the same page yet. Let me go back a step. The demographic service (patient look up, address, date of birth etc) is usually already existing when we add an EHR service. For this reason openEHR, although it has a demographic model, has not had pressure to implement it. The archetypes that you found on the openEHR site were built by hand to demonstrate the application of ADL to another reference model (you will find HL7 RIM archetypes as well). Archetypes are specific to a reference model class – and the demographic and EHR models are not the same (but data structures, clusters, elements are shared by both). So it is possible to share cluster archetypes in the EHR and demographic environments. So archetypes of PARTY in the demographics area cannot be used in the EHR – but a cluster for name or address can be. Does that make sense now? The newer ones under the person icon in CKM conform to the demographic model . These have been created in Brazil. There are cluster archetypes that also have demographic features – which can be stored in the EHR (remember that the EHR model and Demographic model share the cluster class. I hope that helps – Sam --- ## Post #25 by @system Hi William We are taking a service oriented approach here and it has benefits. You can store demographics in the EHR if you like and there are archetypes to allow for this. But generally this data is stored elsewhere in real systems. It is used for administration, billing and a lot of other things. Many hospital have large systems before they implement the EHR. So the EHR as a service can exist without recording the demographic information in the EHR itself. In France it is illegal to do so – requiring separate security to get access to demographic and personal health information. In our environment, the EhrGate component manages the interface to the demographic service – allowing demographics to be returned in queries and for accountability etc. This could be from an openEHR demographic service if that was suitable for that environment – or any other demographic system. Finally, any information between systems is sent as an extract. This brings together the demographic and personal health information for transport, production of a CDA or whatever is required. I hope this helps. It might not seem intuitive but it is very practicle and a result of a lot of companies being involved in the architecture design (all with different demographic services and requirements). Cheers, Sam --- ## Post #26 by @system Sam, I often brought this subject up, maybe five times last year, the answer differed from, "We'll add demographic archetypes to the ArchetypeEditor within a year" to now carefully stating in a direction that demographic archetypes will loose the relevance. I know Sam, the latter is your position for longer time. I believe, we have to distinguish the position of Ocean as a company, and the definition of openEHR as a worldwide concept/standard. As I said before, I don't think that Ocean should add demographic archetypes to their tooling. It would be nice if they do so, but that is their choice. They are a company, and have their own priorities. You are addressing WIlliam in this message, but it is a message on a public mailinglist. I see your message as indirectly addressed to the community. So I am not answering for William, I am answering on my own behalf. I am building software based on openEHR, and I also have to deal with these questions and positions. It is very easy to build a demographic service based on archetypes and RM. I have done that. So I have a need for demographic archetypes. It is also very well possible to connect a demographic service which is not based on OpenEHR. My customers have a choice. It is also possible to use messages of al kind, and archetypes based on the message structures to import demographic data, this is very useful for organisations which want to migrate to an openEHR system. This is possible because of the design of flexibility in the archetypes-concept. The interface/API I created has only the possibility to import demographic data based on archetypes, and to recognize these data as being demographic and therefore to store that in the demographic service, without any extra programming effort. If a customer has a demograpic service that is not based on OpenEHR, it probably publishes its own API to be used. So, in my API I am only dealing with demographic data based on OpenEHR/archetypes. I can, if the customer wants, cosmetically integrate his demographic-service API (if it is not based on OpenEHR) in my own API, so it looks like a single interface to be used. In that case, there will be no demographic archetypes be needed in the system, in that case my system does not process demographic data, only references them. OpenEHR is scaleable, that is one of its powers. Scaleable means, it can fit to small scales too. In small environments, there may be a need for a locally demographic service. What is also important. OpenEHR has done a lot of effort to be flexible, to fit in as many health inforation system-requirements as possible, even in requirements which are not yet defined. Or which are defined in a far away country of which we haven't thought yet. It is not said that laws anywhere in the world will allow demographic data to be centralized and shared. In the Netherlands, at this moment, 300.000 people choose not to be added to a national health information system. This number is expected to grow when the national healthcare system becomes a fact. This means that demographic data will stay locally on the healthcare sites, for example, a GP, a dentist, a hospital. This means, the Dutch systems tolerates contradictory demographic data. The dentist may not know that you are married, if you don't want him to know that. It is a design choice based on what people want. The people in the Netherlands have a possibility to opt out of the national healthcare system. OpenEHR must facilitate that, and it does. It can run with integrated demograpic data, or separate demographic service, being based or not based on openEHR. Very flexible. Regarding to OpenEHR itself. It is technically possible to remove the demographic section complete, because, in fact, the demographic rm-classes are no more than datastructures with a special typename which indicates being demographic. One could conclude that they are, for that reason superfluous. But there are advantages to having a demographic section, f.e. a future possibility to make changes to the demographic RM-part part only. An other advantage is that there is a way to technical distinguish if a RM-datatructure contains demographic data, in this way helping to avoid to blur the demographic service concept, and let slip demographic-data into the EHR-data. Bert Sam Heard schreef: --- ## Post #27 by @ian.mcnicoll Hi Bert, Just for clarification, the work I have been doing in adding demographics archetype support to the Ocean Editor is a personal project, intended for the openEHR community and not an Ocean funded or directed project\. This was largely to help me understand the inner workings of the Editor and for my own education, but I was aware that there has been increasing interest in the wider openEHR community in the Demographics model e\.g\. the work done in Brazil and the original query by William\. This is not a high priority piece of work for me and will take some time to complete \. When the code is a little more stable I will put it up on Subversion as a Branch on the Archetype Editor project I must confess to being a bit surprised by the amount of heat that this topic has generated\!\! Demographics are, of course, a crucial aspect of any EHR and the openEHR Demographics model provides a very elegant set of base classes on which to base archetypes for the key concepts of party, role, contacts , addresses etc\. These are referenced from the main 'EHR model' via 'party\_refs' which adds a layer of confidentiality to the EHR data and allows other demographics models to be used instead\. As Sam has explained, and I think you have agreed, the complexity and variety of pre\-existing national and vendor demographics models makes it unlikely that the openEHR Demographics model will be a priority area in the near future but may find favour in completely new EHR developments\. For me this was simply an opportunity to delve a little deeper into the technical aspects of openEHR, hopefully making a small contribution to the open source base, without tripping up too much on mainstream EHR model developments\. It should be noted that the Demographics Model restricts itself to very 'pure' demographics i\.e\. person and other party identifiers and contact details, as would be expected in a patient register\. Anything else e\.g Housing details, language requirements etc should be modelled in the EHR Model \(though again, in reality, there may be some local variation in implementation\.\) Cheers, Ian Ian Dr Ian McNicoll office / fax \+44\(0\)141 560 4657 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian@mcmi\.co\.uk Clinical Analyst Ocean Informatics ian\.mcnicoll@oceaninformatics\.com BCS Primary Health Care Specialist Group www\.phcsg\.org --- ## Post #28 by @system Ian McNicoll schreef: > ``` > Hi Bert, > > Just for clarification, the work I have been doing in adding > demographics archetype support to the Ocean Editor is a personal > project, intended for the openEHR community and not an Ocean funded or > > ``` Thanks Ian, for your reply. I didn't know that the ArchetyoeEditor supports demograpic archetypes. I answered to the complain from William that it did not, and others confirming this. I knew it did not support demographic archetypes a sometime ago. And thus, I am surprised to hear from you that you are adding support for demographic archetypes. Which is good news. Me, for myself, getting tired of this issue, started a few days ago withn diving into the sourcecode of the LiU Archetype-Editor. But it cost hours only to get the project compiling, because the code is not maintained for some time, and things on which it depends have changed. And time really is a problem, I can only work one or two hours in the evening on this. > ``` > directed project. This was largely to help me understand the inner > workings of the Editor and for my own education, but I was aware that > there has been increasing interest in the wider openEHR community in > the Demographics model e.g. the work done in Brazil and the original > query by William. This is not a high priority piece of work for me and > will take some time to complete . When the code is a little more > stable I will put it up on Subversion as a Branch on the Archetype > Editor project > > ``` This is a very good idea, it not only serves the possibility for people to use it, but also, and that is important, it helps creating the eco-system around OpenEhr, which is necessary to make the concept a success. It is for some people surprising that the support for demographics is not in the ecosystem. And what people put in the demographic session, it is up to them, OpenEhr offers flexibility, that is its power. There are discussions about that, often on the list. I do not participate often, because, I want to be a system-builder of a flexible system. Let the customer decide what is best for his/her system. Bert --- ## Post #29 by @system Bert Verhees schreef: > Ian McNicoll schreef: > > > ``` > > Hi Bert, > > > > Just for clarification, the work I have been doing in adding > > demographics archetype support to the Ocean Editor is a personal > > project, intended for the openEHR community and not an Ocean funded or > > > > ``` > > Thanks Ian, for your reply. > > I didn't know that the ArchetyoeEditor supports demograpic archetypes. I didn't know that the ArchetypeEditor *is going to* support demograpic archetypes. (read your message to quick, excuse me) Bert --- ## Post #30 by @system Thanks for this Bert – a very helpful summary of the situation. Cheers, Sam --- ## Post #31 by @yampeku Last Friday I built an XSD schema following the openEHR demographics model available on the openEHR web\. I have been able to import it to LinkEHR and do some test with the available demographic archetypes \(thanks Sergio\) and seems to work well\. I've uploaded it to the LinkEHR webpage so anyone can try it\. Check the download section of http://www.linkehr.com The XSD schema can be downloaded there too\. Diego --- ## Post #32 by @Oxford_Partnership Hi Ian Are you extending the existing ADL parser to deal with the Demographic classes - it would be very interested in seeing that. thanks OP --- ## Post #33 by @Oxford_Partnership Are there any defining rules as to what data should exist within the EHR vs Demographic models ?. regards OP --- ## Post #34 by @ian.mcnicoll Hi , The ADL parsers \(both \.NEt and Eiffel\) do already parse Demographics model archetypes\. I am working \(slowly\) on adding Demographics model support to the Ocean Archetype Editor\. One things are a little more advance I will create a branch in the Archetype editor subversion repository\. Ian Dr Ian McNicoll office / fax \+44\(0\)141 560 4657 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian@mcmi\.co\.uk Clinical Analyst Ocean Informatics ian\.mcnicoll@oceaninformatics\.com BCS Primary Health Care Specialist Group www\.phcsg\.org --- ## Post #35 by @system And the Java ADL parser supports demographic archetypes too\. In fact, the parsers don't care if the archetype is about EHR or Demographics\. As long as the archetype has the correct ADL synatx, they are happy =\) Cheers Rong --- ## Post #36 by @thomas.beale General principles: EHR: - clinical data - clinically relevant demographic details, e.g. sex, date of birth, occupation - but otherwise, identifying information, and even patient id(s) can be avoided completely in the openEHR EHR, or they can be put in; see Common IM for discussion - [http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf](http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf) - clinically relevant admin data, e.g. admission, discharge, transfer, birth, death, .... Demographic: - demographic data of any complexity, including personal contact information, professional qualifications - relationships, typically for relating professionals together into teams, groups and to employing organisations - thomas beale Oxford Partnership wrote: [details="(attachments)"] ![OceanC_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #37 by @system Shouldn't we consider to extend the Demographics to Resources? Isn't a person one of many types of resources we need to document in and around the EHR? (e.g. devices, catalogs with lab tests or procedures, rooms, beds, ad-hoc lists, etc) Gerard -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: [gfrer@luna.nl](mailto:gfrer@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 --- ## Post #38 by @ian.mcnicoll Hi Thomas, Good summary which I would agree with in principle, but this only properly applies where openEHR is being used to completely define the information requirements\. In practice, openEHR is really being used in 3 slightly different contexts\.\.\. 1\. Where applications are being developed with a pure openEHR 'back\-end' covering both the EHR and Demographics models\. In this context, a clear separation of models with the spilt of content you have defined above, is the correct design\. 2\. Where applications are being designed with an openEHR back\-end to cover the EHR content but integrated with an existing Patient Admin system \(PAS\) or other pre\-defined Demographics model e\.g a national standard, HL7\-CDA\. In this case, the pure separation you defined above may not be acheivable e\.g\. the PAS or national model may include some aspects thatshould be in EHR such as Sex or Occupation\. Alternatively, it may be that the existing model will not allow some 3rd parties such as carers or other contacts to be stored in the PAS, so these will have to be modelled in the EHR\. 3\. Where openEHR is used purely to gather and define clinical content, with no expectation that either the EHR or Demographics models will utlimately be modelled as openEHR within consuming applications\. This can cause some difficulties since, for instance, while an archetype for surgical procedure does not need to explicitly model the surgeon and any assistants as this is already catered for within by the Participants attribute, clinical reviewers of the archetype or templates, do like to be able to see this represented, often structured within the main definition of the archetype\. This was the main reason that for the NHS modelling, we created some CLUSTER archetypes, representing concepts like Organisation, Address,Carer etc\. So although I mostly agree with Thomas's definitions as they apply to a pure openEHR system, there are other circumstances where the overall context of openEHR use is the key determinant\. The original design decision to make a clear separation between the EHR and Demographics models makes perfect sense in the context of a pure openEHR implementation, but we may have to explore the possibility of being able to show some aspects of the Demographics model within an archetype tree, to cope with legacy PAS and design\-only contexts of openEHR use\. Ian Dr Ian McNicoll office / fax \+44\(0\)141 560 4657 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian@mcmi\.co\.uk Clinical Analyst Ocean Informatics ian\.mcnicoll@oceaninformatics\.com BCS Primary Health Care Specialist Group www\.phcsg\.org --- ## Post #39 by @ian.mcnicoll Hi Gerard, I think this is theoretically and philosophically correct\. However,for the moment, given the difficulties I have described above, on achieving a clear separation between Demographic and EHR entities in practice, that at present, this would only confuse things further\. At present it is helpful to be able to model Device explicitly and visibly within archetypes\. We use a CLUSTER archetype so that this is reusable and extensible\. We do already have external catalogs for e\.g\. lab tests, procedures and medications etc but the problem \(as for the Demographics entities\) is that the internal requirements for the catalog are usually a mismatch for the requirements in the clinical record\. It would of course be possible to use the maximal dataset approach to define, for instance, an archetype for device which encompassed a variety of different perspectives \- use in the clinial record, manufacturer's requirements, servicing records, scheduling etc but as ever, it is question of resources\.It is going to be hard enough to model the clinical record requirements without taking on this extra work\. Ian Dr Ian McNicoll office / fax \+44\(0\)141 560 4657 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian@mcmi\.co\.uk Clinical Analyst Ocean Informatics ian\.mcnicoll@oceaninformatics\.com BCS Primary Health Care Specialist Group www\.phcsg\.org --- ## Post #40 by @thomas.beale Gerard Freriks wrote: --- ## Post #41 by @thomas.beale Ian McNicoll wrote: > ``` > Hi Thomas, > > Good summary which I would agree with in principle, but this only > properly applies where openEHR is being used to completely define the > information requirements. In practice, openEHR is really being used in > 3 slightly different contexts... > > 1. Where applications are being developed with a pure openEHR > 'back-end' covering both the EHR and Demographics models. In this > context, a clear separation of models with the spilt of content you > have defined above, is the correct design. > > 2. Where applications are being designed with an openEHR back-end to > cover the EHR content but integrated with an existing Patient Admin > system (PAS) or other pre-defined Demographics model e.g a national > standard, HL7-CDA. In this case, the pure separation you defined > above may not be acheivable e.g. the PAS or national model may include > some aspects thatshould be in EHR such as Sex or Occupation. > Alternatively, it may be that the existing model will not allow some > 3rd parties such as carers or other contacts to be stored in the PAS, > so these will have to be modelled in the EHR. > > ``` well there will clearly be overlaps between the EHR and PAS - sex, date of birth and occupation seem unavoidable. As a general approach, I believe an openEHR demographic service should always be deployed, usually as an interface to / mirror of a PAS or other PMI (but providing versioning, and proper archetyping). We still don't want to pollute individual patient EHRs with multiple redundant copies of information about various carers etc. > ``` > 3. Where openEHR is used purely to gather and define clinical > content, with no expectation that either the EHR or Demographics > models will utlimately be modelled as openEHR within consuming > applications. This can cause some difficulties since, for instance, > while an archetype for surgical procedure does not need to explicitly > model the surgeon and any assistants as this is already catered for > within by the Participants attribute, clinical reviewers of the > archetype or templates, do like to be able to see this represented, > often structured within the main definition of the archetype. This was > the main reason that for the NHS modelling, we created some CLUSTER > archetypes, representing concepts like Organisation, Address,Carer > etc. > > ``` but this is faulty modelling - archetype is not the place to do such modelling - it is being misused in this instance to express the requirement / aspiration of having a form on the screen with a fully populated demographic items. The requirement is reasonable of course, but needs to be modelled elsewhere - it is the job of a virtual EHR service to integrate information from EHR, demographics and other services and present it on the screen in appropriate forms. - thomas --- ## Post #42 by @ian.mcnicoll Hi Thomas, > TB: > We still don't want to pollute individual patient EHRs > with multiple redundant copies of information about various carers etc\. > In principle, I absolutely agree, but if in an existing PAS is to be interfaced/mirrored, we must accept that the faciliites e\.g to record carers, may simply not be available\. As an EHR vendor, I can see the attraction of just getting on with modelling this in my EHR \. > TB > but this is faulty modelling \- archetype is not the place to do such modelling \- it is being misused in this instance to express the >requirement / aspiration of having a form on the screen with a fully populated demographic items\. The requirement is reasonable of >course, but needs to be modelled elsewhere \- it is the job of a virtual EHR service to integrate information from EHR, demographics and > other services and present it on the screen in appropriate forms\. Again, I cannot disagree but whilst the openEHR architecture and tooling has been largely successful in appopriately obscuring the technical aspects of modelling from clinical modellers, this is an aspect that we have not got quite right as yet\. First off we need to be able to develop Demographics model archetypes via clinically useable tools \(which is happening and is where this thread started\) and then we must be able to display them within the tools in an understandable and contextually appropriate fashion\. Whilst much of this could be done at template level, there are situations where, from a user perspective, this is counter\-intuitive\. As I said before, the strength of openEHR has been to be able to present clinical information in an immediately understandable fashion, no matter that the underlying technical model is quite different\. As an example, perhaps we have an operation note archetype, where the surgeon and any assistants should be defined\. This is, of course already handled by Participations and ideally could be shown explicitly in the template, complete with Demographics archetypes to define the exact participant data required e\.g \.Name , Address, Grade, Role \. However, perhaps there is also a legal/training requirement that the lead operator start/stop time is captured i\.e when the assistant takes control\. This clearly forms part of a per\-patient record but relates at node\-level to a particular Participant\. Possibly this is just a tooling issue but I have wondered whether it might be helpful to allow some sort of 'design\-time' attribute to be applied to a node which indicates that the node should not be instantiated in data but is simply there as a placeholder for e\.g a reference to a particular participant or indeed to another part of the underlying Ref model which is clinically important but not archetypeable e\.g Date performed in the ACTION class, but which is important for clinicians to see\. It could also be used to allow assertions to be made visible and editable within correct clinical context\. Ian Dr Ian McNicoll office / fax \+44\(0\)141 560 4657 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian@mcmi\.co\.uk Clinical Analyst Ocean Informatics ian\.mcnicoll@oceaninformatics\.com BCS Primary Health Care Specialist Group www\.phcsg\.org --- **Canonical:** https://discourse.openehr.org/t/why-is-the-editor-not-opening-adl-files/13890 **Original content:** https://discourse.openehr.org/t/why-is-the-editor-not-opening-adl-files/13890