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 at mcmi.co.uk Clinical Analyst Ocean Informatics ian.mcnicoll at oceaninformatics.com BCS Primary Health Care Specialist Group www.phcsg.org 2009/3/20 Bert Verhees <bert.verhees at rosa.nl>: > 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: > > 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 > > > > From: openehr-technical-bounces at openehr.org > [mailto:openehr-technical-bounces at openehr.org] On Behalf Of > Williamtfgoossen at cs.com > Sent: 17 March 2009 00:56 > To: openehr-technical at openehr.org > Subject: Re: Why is the editor not opening ADL files? > > > > 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 at 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 at cs.com > williamtfgoossen at cs.com > info at results4care.nl > > phone + 31654614458 > fax +3133 2570169 > www.results4care.nl > Dutch Chamber of Commerce number: 32133713 > > ________________________________ > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
