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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090320/64343bae/attachment.html>
