Hi all,
Which archetypes are best to use for demographic-purposes. I found the
ones in knowledge/archetypes/dev/adl/openehr/demographic but they seem
uncomplete to me. I found an archetypeslot to
openehr-list_s.person_name.*, but then I cannot find that archetype. SO
what can I do best, to build demographic datacollection?
Thanks
Bert
Hi Bert
Ian McNicholl has developed a number for the NHS for use in clinical records (rather than demographic systems). It is probably worth drawing your attention to these and how they are used in templates. I would be interested in getting these into the openEHR space.
Cheers, Sam
Bert Verhees wrote:
Sam Heard schreef:
Hi Bert
Ian McNicholl has developed a number for the NHS for use in clinical
records (rather than demographic systems). It is probably worth
drawing your attention to these and how they are used in templates. I
would be interested in getting these into the openEHR space.
Thanks Sam,
Dear Ian
I am very interested in these demographic archetypes, can you please
send them to me. I will, if possible, make them fit for the Netherlands,
and eventually (if there are no objections from the community) post them
to the OpenEhrspace
regards
Bert Verhees
Just for info. The design for these archetypes came from the Scottish NHS XMl messaging standard (we do not use HL7 as they do in England).
The schema for these is at
http://www.isdscotland.org/isd/files/general-v2-7.xsd
NHS Scotland Interoperability Working Group http://www.isdscotland.org/isd/5194.htm
originally based on: Personal name of the person. ENV 13606 - 4:2000 7.11.12
Ian
Currently at
http://svn.openehr.org/knowledge/archetypes/dev-uk-nhs/adl/openehr/ehr/cluster/openEHR-EHR-CLUSTER.person_address.v1draft.adl
http://svn.openehr.org/knowledge/archetypes/dev-uk-nhs/adl/openehr/ehr/cluster/openEHR-EHR-CLUSTER.person_demographics.v1draft.adl
http://svn.openehr.org/knowledge/archetypes/dev-uk-nhs/adl/openehr/ehr/cluster/openEHR-EHR-CLUSTER.person_name.v1draft.adl
http://svn.openehr.org/knowledge/archetypes/dev-uk-nhs/adl/openehr/ehr/cluster/openEHR-EHR-CLUSTER.person_telecoms.v1draft.adl
http://svn.openehr.org/knowledge/archetypes/dev-uk-nhs/adl/openehr/ehr/cluster/openEHR-EHR-CLUSTER.professional_role.v1draft.adl
http://svn.openehr.org/knowledge/archetypes/dev-uk-nhs/adl/openehr/ehr/cluster/openEHR-EHR-CLUSTER.care_professional.v1.adl
http://svn.openehr.org/knowledge/archetypes/dev-uk-nhs/adl/openehr/ehr/cluster/openEHR-EHR-CLUSTER.address.v1draft.adl
http://svn.openehr.org/knowledge/archetypes/dev-uk-nhs/adl/openehr/ehr/cluster/openEHR-EHR-CLUSTER.organisation.v2draft.adl
http://svn.openehr.org/knowledge/archetypes/dev-uk-nhs/adl/openehr/ehr/cluster/openEHR-EHR-CLUSTER.individual_personal.v1draft.adl
http://svn.openehr.org/knowledge/archetypes/dev-uk-nhs/adl/openehr/ehr/cluster/openEHR-EHR-CLUSTER.individual_professional.v1draft.adl
Ian
Thanks very much, Ian, now we have something, quite much to study
Bert
Ian McNicoll schreef:
Please excuse me for coming back to this, almost a year later.
Again I am on the point where I want to maintain code for the EHR-structure. Still I have the same questions…
The point is, I can hardly find archetypes based on this, but I find more archetypes based on more generic data-structures like CLUSTER, like the nhs-archetypes, listed below, URL has changed since, but they still exist. But there are almost no archetypes published based on the Demographic subtree of the RM-model.
Thomas Beale schreef:
> Another question, how do people from the NHS, who built many many > archetypes, but none on demographic base construct their EHR's? > in the NHS so far there is no real EHR, only something called PSIS aka the 'Spine' (see [http://www.connectingforhealth.nhs.uk/resources/systserv/spine-factsheet](http://www.connectingforhealth.nhs.uk/resources/systserv/spine-factsheet)). This has only a very basic architecture at the moment. They have not really decided on an EHR architecture yet.
That is OK, then, we are not to use the NHS archetypes, I understand.
Thomas Beale schreef:
> Does that mean that the demographic classes in the Reference Model > will > go the same way? > Hi Bert, on the contrary, demographic archetypes and demographic a archetype editor capability will have increased development around them in 2008.
The latest version of the Archetype-editor from Ocean (may, 2008) does still no support this kind of archetypes.
Again, what is the future of the Demographic part of the RM-model? Still there are not many examples (almost none) and no software-tooling-support.
What are the reasons for this?
Thomas Beale schreef:
> Now my question, how can we facilitate an EHR-construction, as > described > in the documentation, using the available archetype-editors? > can you be more precise about what you mean here - building an EHR itself is not the business of an archetype editor....
I don’t understand this. In my opinion, an EHR is build up in datastructures which are defined by archetypes, some of them are of based on Demographic. Thus, it is not possible to construct an EHR, using the archetype-editors as available.
(It is no problem, one can always build an archetype in vi, and test it afterwards.)
I just want to know what I misunderstand.
Thomas Beale schreef:
> Or is it more or less that that we are to use the Party-ref as an > Object-ref, and do not take the specifications to literally? (because, > they, f.e. will be updated in the future) > can you be more precise here?
This was more or less a joke, an EHR-Status contains a Party-Ref. If the demographic would disappear, (or like NHS, are not used) it is not possible to create an EHR according to the specs.
But as I said, this was more or less a joke.
Nevertheless, the practical issues around the demographic puzzle me still.
So I have two questions
Thanks,
Bert
Ian McNicoll schreef (19-nov-2007):
Hi Bert,
We designed some archetypes based on openehr demographic rm, and taking into account ISO/WD 22220 (Identification of subjects of health care), ISO WD for Provider Identification and our knowledge of how Brazilian health system works. I will send them to you in a separate e-mail. Note that they are still a draft and are in Portuguese. Eventually I may translate them to English, but in the meantime feel free to ask any questions and use them as you wish. I will also send a copy to Thomas Beale so that openEHR Foundation may use them as it sees fit.
Cheers,
Sergio
Sergio Miranda Freire schreef:
Hi Bert,
We designed some archetypes based on openehr demographic rm, and taking into account ISO/WD 22220 (Identification of subjects of health care), ISO WD for Provider Identification and our knowledge of how Brazilian health system works. I will send them to you in a separate e-mail. Note that they are still a draft and are in Portuguese. Eventually I may translate them to English, but in the meantime feel free to ask any questions and use them as you wish. I will also send a copy to Thomas Beale so that openEHR Foundation may use them as it sees fit.
Thank you very much, Serfio, I’ll study them tomorrow. I think, I can translate most of ot to English and Dutch without much problems.
reggards
Bert
(CC'd to the implementers list)
Sergio,
I also want to say thanks for sharing these archetypes.
I am not an archetype expert but there is something about these that
confuse me. (as Sergio and I have discussed a bit). Maybe someone can
UN-CONFUSE me?
In the simple email address one pasted below (definition only for
brevity). In the definition section the ADDRESS class is shown to have
an attribute of 'details' (correct according to the RM). However,
'details' is supposed to be of type ITEM_STRUCTURE (so therefore it
should be an ITEM_LIST???). As well, the ELEMENT should have as its
contents a descendant of DATA_VALUE. CODED_TEXT is not; nor is
CODED_TEXT a class within the AM or RM.
So are these archetypes syntactically correct (checked in the ADL
Workbench) but just not valid with the openEHR information model?
OR! am I missing something?
--Tim
archetype (adl_version=1.4)
br-demographic-ADDRESS.email.v1
...
definition
ADDRESS[at0000] matches { -- correio eletrônico
details matches {
LIST[at0001] matches { -- Itens do e-mail
items cardinality matches {1..*; ordered} matches {
ELEMENT[at0002] occurrences matches {0..1} matches { -- Tipo de
correio eletrônico
value matches {
CODED_TEXT matches {
code matches {
[local::
at0003, -- pessoal
at0004] -- comercial
}
}
}
}
ELEMENT[at0005] occurrences matches {1} matches { -- correio
eletrônico
value matches {
DV_TEXT matches {*}
}
}
}
}
}
}
Hi Tim,
If you open ocean archetype editor, or liu ae, start a new clinical archetype, add a list of elements (two of them being a text and a coded text, respectively), and check the adl for it, you will see ITEM_LIST, DV_TEXT, and DV_CODED_TEXT, as you would expect.
So why the types TEXT and CODED_TEXT that appear in many archetypes, including the famous blood pressure archetype, and LIST that is in openehr-demographic-address.location_address.draft.adl ?
I do not have an answer for that, I only may make some guesses. Maybe they are reminiscents of previous versions of editors and openEHR rm, I don't know. I guess that if you were to deserialize an adl file into objects from the AOM, whenever you find a TEXT you would have to set the rm_type_name attribute from the corresponding C_OBJECT object to DV_TEXT, and do similar things when you find CODED_TEXT or LIST. I hope that someone can clarify these matters.
Finally, when we started editing the demographic archetypes, we used a text editor, since we don't have editors for demograhic archetypes yet. And we used openehr-demographic-address.location_address.draft.adl as our starting point. That's why you will see LIST, TEXT, and CODED_TEXT in many of them. Now I think we need some guidelines on how to proceed. Are these terms deprecated or something like that?
Regards,
Sergio
-----Mensagem original-----
Hi Tim,
If you open ocean archetype editor, or liu ae, start a new clinical archetype, add a list of elements (two of them being a text and a coded text, respectively), and check the adl for it, you will see ITEM_LIST, DV_TEXT, and DV_CODED_TEXT, as you would expect.
So why the types TEXT and CODED_TEXT that appear in many archetypes, including the famous blood pressure archetype, and LIST that is in openehr-demographic-address.location_address.draft.adl ?I do not have an answer for that, I only may make some guesses. Maybe they are reminiscents of previous versions of editors and openEHR rm, I don’t know. I guess that if you were to deserialize an adl file into objects from the AOM, whenever you find a TEXT you would have to set the rm_type_name attribute from the corresponding C_OBJECT object to DV_TEXT, and do similar things when you find CODED_TEXT or LIST. I hope that someone can clarify these matters.
Yes, these are indeed relics from old model and tools. The correct types are ITEM_LIST and DV_TEXT according to the latest RM specification (Release 1.0.1). I suspect that some tools still support incorrect (shortened names) for backwards compatibility when the archetypes are opened, but the correct types should be used when the archetypes are serialized from the editor.
/Rong
Hi Sergio,
Thanks for your explanation.
Yes, these are indeed relics from old model and tools. The correct
types are ITEM_LIST and DV_TEXT according to the latest RM
specification (Release 1.0.1). I suspect that some tools still support
incorrect (shortened names) for backwards compatibility when the
archetypes are opened, but the correct types should be used when the
archetypes are serialized from the editor.
Thanks for this clarification Rong.
I suppose the tools should at least through a deprecation warning in
these cases instead of apparently validating the ADL. Though this isn't
really the total solution (AFAIK) since ADL can be syntactically correct
against any reference model.
Since I am not intimately familiar with any of the archetype
building/validating tools. Do they provide a selection as to the RM that
the archetype is supposed to be valid against? Let's say openEHR or
EN13606?
I'm doing a new checkout of the knowledge base so I can include them on
a CD we're distributing at the workshop next weekend. I'm going to
search across the existing adl files and see how many instances of
"CODED_TEXT" and "LIST" I find.
AFAIK the CRB hasn't actually certified any archetypes yet so this isn't
a big issue at this point. But, as openEHR becomes more widely known and
used .... ???
I wonder if the new CRB Chair has a plan to address this? I have CC'd
Tony in case he isn't on the implementers list.
--Tim
Hi Sergio,
Thanks for your explanation.
Yes, these are indeed relics from old model and tools. The correct
types are ITEM_LIST and DV_TEXT according to the latest RM
specification (Release 1.0.1). I suspect that some tools still support
incorrect (shortened names) for backwards compatibility when the
archetypes are opened, but the correct types should be used when the
archetypes are serialized from the editor.Thanks for this clarification Rong.
I suppose the tools should at least through a deprecation warning in
these cases instead of apparently validating the ADL. Though this isn’t
really the total solution (AFAIK) since ADL can be syntactically correct
against any reference model.Since I am not intimately familiar with any of the archetype
building/validating tools. Do they provide a selection as to the RM that
the archetype is supposed to be valid against? Let’s say openEHR or
EN13606?
Hi Tim,
Syntactically valid archetypes in ADL need to be further validated against a specific RM. For existing archetypes, the tools usually pick up the model from the archetype ID and can use the indicated RM for validation. For creating a new archetype, an archetype editor should normally ask for the RM to be used as the very first step.
Cheers,
Rong
Hi Sergio and Tim,
Yes, these archetypes are old and should reflect the RM exactly. Ocean has been developing some demographic archetypes to be used in a non-health application and have used the Ocean Archetype Editor to do this. Instead of using a PARTY class we have used an ADMIN_ENTRY and instead of a ITEM_TREE/ITEM_LIST we have used a CLUSTER. These can then be converted into the demographic RM simply by manually changing the Archetype root class (ADMIN_ENTRY/CLUSTER) to the demographic model equivalent (PARTY/ITEM_xxx). This manually modified archetype cannot be loaded back into the Archetype Editor but could be now maintained manually and validated in the Archetype Workbench.
This work around is obviously hard work and there is an obvious need for Demographic RM support in the Archetype Editors. The Ocean Archetype Editor is open source, so if anyone would like to make a contribution to provide this support then please do not hesitate to contact me.
Regards
Heath
Heath Frankel
Product Development Manager
Ocean Informatics
email: heath.frankel@oceaninformatics.com
Hi Tim
It sounds as though these are based on short hand labels. Sergio, you need to ensure that the classes are in the RM (ITEM_LIST, DV_CODED_TEXT)
Cheers, Sam
Tim Cook wrote:
Heath Frankel schreef:
Hi Sergio and Tim,
Yes, these archetypes are old and should reflect the RM exactly. Ocean has been developing some demographic archetypes to be used in a non-health application and have used the Ocean Archetype Editor to do this. Instead of using a PARTY class we have used an ADMIN_ENTRY and instead of a ITEM_TREE/ITEM_LIST we have used a CLUSTER. These can then be converted into the demographic RM simply by manually changing the Archetype root class (ADMIN_ENTRY/CLUSTER) to the demographic model equivalent (PARTY/ITEM_xxx). This manually modified archetype cannot be loaded back into the Archetype Editor but could be now maintained manually and validated in the Archetype Workbench.This work around is obviously hard work and there is an obvious need for Demographic RM support in the Archetype Editors. The Ocean Archetype Editor is open source, so if anyone would like to make a contribution to provide this support then please do not hesitate to contact me.
Thank you for this workaround, it is a bit tricky, manually, without
software-support rebuilding archetypes, but the good news is that we
have some check-tools, like the ADL-workbench and the parser-code in java
So we need to use "vi" or "notepad" to create demographic archetypes,
and that won't change in short time. Maybe a "vim"-template for
syntax-coloring could help. Or Eclipse-archetype-editor with automatic
suggest/completion function. I think these are things that will come,
maybe I will create some of them myself. And maybe I will change the
Archetype-editor also, but first I need a computer to run Windows and
Visa Studio to do so. Or maybe it is compilable in mono?
Later, when I am less busy, and finished my openehr-application/kernel.
It is a strange thing, with the demographics-archetypes, and I would
hope to see an explanation why that is.
The ocean-editor does not support them
The Liu/java editor does not support them
The NHS does not use them (but use generic archetypes for demographic
information)
There are hardly any examples, maybe two or three, which aren't even
complete.
Even in EhrView, it is not possible to view the XML of demographic
entries (and so is the archetype-structure hidden).
I wonder why that is, can someone explain that? It can't be that they
are too complicated, because other locatable constructions can be
complicated to.
Which mysterious reason is behind this.
Thanks
Bert
If you are able to define an XML Schema for the OpenEHR demographic
model (I couldn't find it on the web) then LinkEHR-ed Archetype Editor
could help you to make those archetypes
Bert,
From Ocean's perspective, it is simply a matter of priorities. There are many existing identity management systems that are deployed and work, some even have trait based mechanisms similar to Archetypes. We have concentrated our development effort in the EHR RM area as this is where openEHR brings something new and major benefits over existing EHR data models. If we had endless resources we would do Demographics as well.
Heath
Heath Frankel schreef:
Bert,
From Ocean's perspective, it is simply a matter of priorities. There are many existing identity management systems that are deployed and work, some even have trait based mechanisms similar to Archetypes. We have concentrated our development effort in the EHR RM area as this is where openEHR brings something new and major benefits over existing EHR data models. If we had endless resources we would do Demographics as well.
Maybe it is a good idea if we (community) can do it. The demographics
are in the specs defined as a necessary part of an EHR, and I think many
people will welcome an archetype-editor which is capable of doing
demographics also. It is a good signal to the world outside the
community to have this.
I wrote you an email separate, for some advise, it would be great if I
(and other developers) get support (if possible) to help to save time on
understanding the complexity of the current code-base for the archetype
editor. For, example, documentation, code-scheme's, easy-startup
understanding, needed libraries, etc.
Nothing is so frustrating as working a week on something and then
discovering that something essential is missing, or searching for days
for something that is just in another location.
Thanks
Bert