Hi, I am working with the final drafts of EN 13606, maybe some information I use is obsolete, please let me know if it is.
Maybe, if I misunderstand something, please let me know.
Shouldn't there be a better distribution of standard-documents (just an idea
to get standards implemented widely)
---------- Doorgestuurd bericht ----------
Hi, I am working with the final drafts of EN 13606, maybe some information I use is obsolete, please let me know if it is.
Maybe, if I misunderstand something, please let me know.-------------------------------------
I have a problem with II, used in GPIC *PatientExtendedInformation*, it has an ID, which is a Set of II.Definition from CEN document:
id O SET<II> One or more identifiers that may be used to uniquely identify the patient
Examples: social security number, health service number, hospital number, case notes number-------------------------------------
I am writing a mapping library from small GP Information Systems to GPIC-objects. And When you create a GPIC-object, it takes care of filling itself with data.
So it creates a list of II, in which the ID's are stored.
At this moment I have following ID's:
- Local GP-Information System ID, which is in most GP-Systems the primary key of the patient-table.
- Insurance numberThe root value is not known to the GP-System, and not known to me, al though this is the only mandatory property, I cannot use it
hi
Because of the way that II works, you do need to get
a root OID. You can get an OID for the GP systems by getting
a container OID from somewhere - HL7 can give you one, but there
should be other providers for your country. Once you have a
container OID, you can extend the OID with a number you assign
for each GP system.
i.e. you get 0.1.2.3.4.5 from nictiz. you assign first gp system 1
so it's OID is 0.1.2.3.4.5.1
So this OID is just a configuration item. The you can append your
localId to the root or treat it as an extension. Theoretically it
should be appended to the root, but I think that treating it as an
extension is more practical.
The assigningAuthorityName is just for convenience, so you put
a text description of how assigned the ID (the OID before
appending the localID)
You can assign the insurance company an OID, or maybe they
already have one, you could ask them. (at this point, I have to say,
I don't think that this OID system is working in practice - it's
very unlikely that they'll know, even if they have one, since likely
they already are assigned one by someone. So, I don't think that the
OID system is working - the II semantics really need effective
OID registries)
*My Question
*How can an automated Process distinguish a InsuranceNumber?
You have to recognise the OID. Sometimes the context will indicate
who's identifier it is, but even that - if it's a good indicator - often
collapses to recognising a different OID
The II datatype needs IMHO a mood-indicator, or else a automated process will never know what to do with one of the ID's.
not sure what you mean here?
Grahame
Grahame Grieve wrote:
<---- snip ----->
So it creates a list of II, in which the ID's are stored.
At this moment I have following ID's:
- Local GP-Information System ID, which is in most GP-Systems the primary key of the patient-table.
- Insurance numberThe root value is not known to the GP-System, and not known to me, al though this is the only mandatory property, I cannot use it
hi
Because of the way that II works, you do need to get
a root OID. You can get an OID for the GP systems by getting
a container OID from somewhere - HL7 can give you one, but there
should be other providers for your country. Once you have a
container OID, you can extend the OID with a number you assign
for each GP system.i.e. you get 0.1.2.3.4.5 from nictiz. you assign first gp system 1
so it's OID is 0.1.2.3.4.5.1So this OID is just a configuration item. The you can append your
localId to the root or treat it as an extension. Theoretically it
should be appended to the root, but I think that treating it as an
extension is more practical.
Thanks Graham, it is clear what you mean.
I must tell you, I work directly on the market, I have customers, who want to get the Insurance-number from a patient in a GP-system, and process it automated.
(I already have difficulties with explaining why they have to use a entityname and find in the connected entityNameParts which one the Lastname is.
Why don't you make a property Lastname, they ask me, and then I explain, that is the way the standard works, and keep telling them the benefits of using a standard.)
Now I must tell them they have to recognize the InsuranceNumbere from the OID which points to InsuranceCompany, somewhere??.
There has to be a service on the Internet where one can translate OID's to friendly names, something like DNS for IP. Or else, this system cannot work
Thanks again, I now know what it is and how to handle it in the future, for now (meantime), I make something up to keep me going.
Thanks Graham, it is clear what you mean.
I must tell you, I work directly on the market, I have customers, who want to get the Insurance-number from a patient in a GP-system, and process it automated.(I already have difficulties with explaining why they have to use a entityname and find in the connected entityNameParts which one the Lastname is.
Why don't you make a property Lastname, they ask me, and then I explain, that is the way the standard works, and keep telling them the benefits of using a standard.)Now I must tell them they have to recognize the InsuranceNumbere from
the OID which points to InsuranceCompany, somewhere??.There has to be a service on the Internet where one can translate OID's to friendly names, something like DNS for IP. Or else, this system cannot work
yes, I know what you mean about standards. I straddle both sides (write and implement)
I agree about a OID registry - a good automated distributed OID registry like the way
that DNS works. I don't know about whether it's being worked on. I would've though it
would be trivial if you based it on LDAP - all we would need is a common schema to use
in the LDAP setups, and some impetus from ISO or something like that.
not sure what you mean here?
Was a stupid remark, I thought, just as with EntityNamePart, where one can tell which kind of name one is reading, one could use a property to tell which kind of ID one is reading, as an optional property. Too bad this is not done.
well, that's how the HL7 v2 identifier works, or doesn't work very well. The problem
is that what kind of identifier something is is relative, and we are in all sorts of
a mess trying to maintain the terminology for that property, to the point where I am
starting to think that it has no safe meaning outside hard-coding it for a particular
implementation. So, in other words, it's ended up collapsing to an arbitrary opaque
string based implementation - like with OIDs, but with added danger because there is
no method of being unique
Grahame
Sorry for my intrusion and my english.
This discussion is very interesting for me and I would like to make some
reflexions, these could be a nonsense and I would like your feedback...
Bert, are you working with openEHR or you only compliance GPIC's?
In openEHR, in the RM.COMMON.IDENTIFICATION package you could find some
classes that perhaps can cover your requirements better, this are
OBJECT_REF, OBJECT_ID and HIER_OBJECT_ID Classes. This is interesting
because a "beautiful" reflexion about identification and reference is doing
in this model...
It seems to me that you are working with demographic knowledge, as I´m
doing. A Person in openEHR only have one unique identification, that is
modeled with and OBJECT_ID, but you can include several identities (as
PARTY_IDENTITY classes), all these IIs that you have in a CEN's Person could
be considered as identities, and the PARTY_IDENTITY class have a purpose
field that can be use for the distintion of the provider of the
identification (as you need) of course the problem is that the value of the
purpose field is a DV_TEXT and the posible values are not normalized...
I think that the problem with the Identification in GPIC for persons is that
all the identifiers are manage in the same way, the distintion between the
unique identifier in the system and the possibles identities of a person is
not doing. The id (set of II's) in a GPIC person can be viewed as object
references, that refer to this person in the same or in other systems... to
mix some ideas from openEHR with CEN could facilitate our work. Don´t you
think so?
Regards,
Isabel Román
Sorry for my intrusion and my english.
I am glad you intruse, the more people the more knowledge is to share,
sometimes this works.
My English is not too good, maybe worse then yours.
This discussion is very interesting for me and I would like to make some
reflexions, these could be a nonsense and I would like your feedback...Bert, are you working with openEHR or you only compliance GPIC's?
Only GPIC's
In openEHR, in the RM.COMMON.IDENTIFICATION package you could find some
classes that perhaps can cover your requirements better, this are
OBJECT_REF, OBJECT_ID and HIER_OBJECT_ID Classes. This is interesting
because a "beautiful" reflexion about identification and reference is doing
in this model...
Please allow me a stupid question: where can I find those classes?
It seems to me that you are working with demographic knowledge, as I´m
doing. A Person in openEHR only have one unique identification, that is
modeled with and OBJECT_ID, but you can include several identities (as
PARTY_IDENTITY classes), all these IIs that you have in a CEN's Person
could be considered as identities, and the PARTY_IDENTITY class have a
purpose field that can be use for the distintion of the provider of the
identification (as you need) of course the problem is that the value of the
purpose field is a DV_TEXT and the posible values are not normalized...I think that the problem with the Identification in GPIC for persons is
that all the identifiers are manage in the same way, the distintion between
the unique identifier in the system and the possibles identities of a
person is not doing. The id (set of II's) in a GPIC person can be viewed as
object references, that refer to this person in the same or in other
systems... to mix some ideas from openEHR with CEN could facilitate our
work. Don´t you think so?
Could be, what ideas do you think of? In my humble opinion, there is a need
for good ideas
I have some more problems with the CEN model which looks like highly build on
theory, but having serious consequences on performance.
The ID's are an example for this.
A single property from PatientExtendedInformation (which is a kind
specialization of Person), the property ID, is loaded with an unlimited
number of ID's, but mostly it will be a few.
As Graham told me, automated processes can only rely on OID to distinguish
ID-kinds. This means there is a need for a service to translate the OID to an
object.
When some process reads that property, the whole load of ID's have to be
loaded into the object, the reader has to resolve the OID's to find out which
one he wants, and than throw away the rest.
For example if the reader wants the Insurance-number, he must resolve all
OID's to find out which one points to an Insurance-company.
In theory, this is fine, clear, but there is also a disadvantage. Standards a
made to use, and if a Insurance-company does not have an OID-service, it
cannot be recognized as such. It makes the standard in that special case
unusable which can result in a paitient having to pay the hospital bill
himself, and later try to get it back from the Insurance-company.
But the bigger problem is that a reading process is forced to load all
possible ID's of a Patient when it wants only one special. That is because
there is no way to distinguish on forehand which Id one wants.
This loading of ID's can result in many database queries in the background,
maybe over slow network connections, maybe to machines which are not on or
crashed or not connected, or disappeared but still have a DNS-entry, etc,
etc, and the process has to wait for a TCP/IP-timeout.
For example, on doing a demographic research, when querying thousands of
patients, this is a killing fact.
Maybe in here lies one important reason of only slow acceptance of standards.
I run against these problems.
But again, I am diving al on myself in this, and it could well be possible
that I misunderstand something. Please teach me gently if so, I will be
thankful.
I have more problems, I will come back to them later, but now this is an
important problem for me
Thanks
Bert Verhees
Bert Verhees wrote:
Now I must tell them they have to recognize the InsuranceNumbere from the OID which points to InsuranceCompany, somewhere??.
There has to be a service on the Internet where one can translate OID's to friendly names, something like DNS for IP. Or else, this system cannot work
right - this is the problem with OIDs - they only really work if they are in global, ubiquitous use. I don't see this happening.
- thomas
Bert Verhees wrote:
In openEHR, in the RM.COMMON.IDENTIFICATION package you could find some
classes that perhaps can cover your requirements better, this are
OBJECT_REF, OBJECT_ID and HIER_OBJECT_ID Classes. This is interesting
because a "beautiful" reflexion about identification and reference is doing
in this model...
Please allow me a stupid question: where can I find those classes?
Bert, you can find all the openEHR models at http://www.openehr.org/repositories/spec-dev/latest/publishing/index.html. I am sorry to say that openEHR data types are not the same as CEN or HL7; instead we built them from the ground based on requirements and a lot of experience from experts in the field. If you want to find out why the data types are different from HL7, see the appendix in the data types IM document.
- thomas beale
There is such a system: DNS. Why in heavens name did we invent a new one?
Bert Verhees wrote:
Now I must tell them they have to recognize the InsuranceNumbere from the OID which points to InsuranceCompany, somewhere??.
There has to be a service on the Internet where one can translate OID's to friendly names, something like DNS for IP. Or else, this system cannot work
right - this is the problem with OIDs - they only really work if they are in global, ubiquitous use. I don't see this happening.
- thomas
-
If you have any questions about using this list,
please send a message to d.lloyd@openehr.org
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
Jan Dockx wrote:
There is such a system: DNS. Why in heavens name did we invent a new one?
DNS is great. In fact, I would suggest that DNS has more chance of including more organisations (represented by their domain names) than ISO OIDs. But...what if a hospital changes domain name, but is still the same hospital? DNS does not have identifying information other than the domain name administrator details (what whois returns); is this enough? In any case, DNS only works for organisations and sometimes pieces of organisations. But how do we want to identify a prescription for example, or a lab result? One way is with an OID; another way is domain_name+lab_result_id. I think the latter is much more realistic today, even if the former seems more theoretically satisfying (even if it completely unreadable to humans;-)
- thomas
Thomas Beale wrote:
Bert Verhees wrote:
In openEHR, in the RM.COMMON.IDENTIFICATION package you could find some
classes that perhaps can cover your requirements better, this are
OBJECT_REF, OBJECT_ID and HIER_OBJECT_ID Classes. This is interesting
because a "beautiful" reflexion about identification and reference is doing
in this model...
Please allow me a stupid question: where can I find those classes?Bert, you can find all the openEHR models at http://www.openehr.org/repositories/spec-dev/latest/publishing/index.html. I am sorry to say that openEHR data types are not the same as CEN or HL7; instead we built them from the ground based on requirements and a lot of experience from experts in the field. If you want to find out why the data types are different from HL7, see the appendix in the data types IM document.
Thanks, even it is not the same as CEN, it helps me understand CEN better. Too bad that we have to deal with three standards. For a technician like me this is terrible, too bad it is hard to get to different views based on different technical experience.
Thomas Beale wrote:
Bert Verhees wrote:
Now I must tell them they have to recognize the InsuranceNumbere from the OID which points to InsuranceCompany, somewhere??.
There has to be a service on the Internet where one can translate OID's to friendly names, something like DNS for IP. Or else, this system cannot work
right - this is the problem with OIDs - they only really work if they are in global, ubiquitous use. I don't see this happening.
Another problem with OID, not everyone may agree, is that they contain no meta-information, betters said, the problem is with II, it offers no property for meta-information meant for automated processing. You can never find out what kind of number you are processing.
I wonder, what does CEN say about this, about your, in their eyes, must be, controversial meaning?
What do they say about OID at all?
They have to believe in the system, they are advising the Dutch government to start implementing CEN-standards next year.
And I am already implementing it, but in a special way.
regards
Bert Verhees
Totally agree. The change in domain name is, BTW, less likely than a change in software vendor. With OID's chances are that not the hospital will have an OID, but the software package installation, as a sub of the software package, as a sub of the software company. FQDN of the software company or the hospital is never worse. And the whois objection is extra: this feature isn't even defined for OID.
Jan Dockx wrote:
There is such a system: DNS. Why in heavens name did we invent a new one?
DNS is great. In fact, I would suggest that DNS has more chance of including more organisations (represented by their domain names) than ISO OIDs. But...what if a hospital changes domain name, but is still the same hospital? DNS does not have identifying information other than the domain name administrator details (what whois returns); is this enough? In any case, DNS only works for organisations and sometimes pieces of organisations. But how do we want to identify a prescription for example, or a lab result? One way is with an OID; another way is domain_name+lab_result_id. I think the latter is much more realistic today, even if the former seems more theoretically satisfying (even if it completely unreadable to humans;-)
- thomas
-
If you have any questions about using this list,
please send a message to d.lloyd@openehr.org
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
Bert Verhees wrote:
I wonder, what does CEN say about this, about your, in their eyes, must be, controversial meaning?
nothing different from HL7 at this stage, but in openEHR we have defined a type DV_IDENTIFIER to do what you are talking about (as well as OBJECT_ID); but this will not help you if you are limited to an HL7 framework.
- thomas
Bert Verhees wrote:
Thanks, even it is not the same as CEN, it helps me understand CEN better. Too bad that we have to deal with three standards. For a technician like me this is terrible, too bad it is hard to get to different views based on different technical experience.
we wish there were not 3 specifications as well. But there are many reasons why we cannot use the HL7 data types. We are also dedicated to requirements basis and implementability for openEHR, and the models you see here I think are by now pretty reasonable attempts on both counts - they are now implemented in various languages, and the requirements are (mostly) clearly indicated. A new version of the openEHR data types specification will be out very soon, fixing some of the details of the UML and so on.
- thomas
Thomas Beale wrote:
Bert Verhees wrote:
Thanks, even it is not the same as CEN, it helps me understand CEN better. Too bad that we have to deal with three standards. For a technician like me this is terrible, too bad it is hard to get to different views based on different technical experience.
we wish there were not 3 specifications as well. But there are many reasons why we cannot use the HL7 data types. We are also dedicated to requirements basis and implementability for openEHR, and the models you see here I think are by now pretty reasonable attempts on both counts - they are now implemented in various languages, and the requirements are (mostly) clearly indicated. A new version of the openEHR data types specification will be out very soon, fixing some of the details of the UML and so on.
- thomas
I had a chat with Gerard Freriks, and he told me that the specs, as described in the CEN-documents are not ready for implementation-purposes. There will be an Implementation Guideline in 2006. Because I am actually the first commercial implementor of the CEN, it is normal I run against al kinds of omissions, unclearities,e tc. Gerard advised me to fill them in myself, and they will be discussed with CEN later. I have of course the risk that interfaces can change, and people using my software have to adopt the changes. The risk will be smaller if I stay as close as possible to the spirit/definitions, now in the standard.
This is a great relieve for me.
regards
Bert Verhees
Dear Open EHR friends,
It appears there are many uncertaintities on the use of OIDs and it has been difficult to find good information about it.
There is a very informative web site I discovered recently which explains a lot about the total systema nd seems to have updated lists of assigned OIDs. In relation to the use as intended by CEN and OpenEHR specifications, I recommend that you make sure you have an organisation in your country related to health that should have a registered OID the easiest should be through your National standards body NEN to obtain one. Search on this to find also contact person.
Then you need to assign specifics for the types of identifiers useed in your country. I agree we should try to get a global registry but it is not the most urgent but to get it to work nationally with the globally unique identifiers. Many people seem to think that there is only a number version of the OID but the international registration system does provide a textual form also used in eg ASN.1. See more on the web. For example the Swedish local Town Skeleftea appears as:
{iso(1) member-body(2) se(752) skelleftea(89)} or just: 1.2.752.89. Not all have been appropirately registered with a name however. It also appears from this web site that NEN has only registered one OID but maybe it is not updated.
Anyway good luck with your implementations.
Gunnar
Gunnar Klein (CEN/TC 251 chariman)