# Problem with Datatype: Instance Identifier (II) **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2005-03-01 13:15 UTC **Views:** 30 **Replies:** 17 **URL:** https://discourse.openehr.org/t/problem-with-datatype-instance-identifier-ii/14487 --- ## Post #1 by @system 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. --- ## Post #2 by @system Shouldn't there be a better distribution of standard\-documents \(just an idea to get standards implemented widely\) \-\-\-\-\-\-\-\-\-\- Doorgestuurd bericht \-\-\-\-\-\-\-\-\-\- --- ## Post #3 by @grahamegrieve > 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 number > > The 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 --- ## Post #4 by @system 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 number >> >> The 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\. 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\. --- ## Post #5 by @grahamegrieve > 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 --- ## Post #6 by @Isabel_Roman 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 --- ## Post #7 by @system > 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 --- ## Post #8 by @thomas.beale 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 --- ## Post #9 by @thomas.beale 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 --- ## Post #10 by @Jan_Dockx 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 http://www.peopleware.be/ http://www.mobileware.be/ --- ## Post #11 by @thomas.beale 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 --- ## Post #12 by @system 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\. --- ## Post #13 by @system 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 --- ## Post #14 by @Jan_Dockx 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 http://www.peopleware.be/ http://www.mobileware.be/ --- ## Post #15 by @thomas.beale 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 --- ## Post #16 by @thomas.beale 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 --- ## Post #17 by @system 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 --- ## Post #18 by @Gunnar_Klein 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\. http://asn1.elibel.tm.fr/oid/ 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\) --- **Canonical:** https://discourse.openehr.org/t/problem-with-datatype-instance-identifier-ii/14487 **Original content:** https://discourse.openehr.org/t/problem-with-datatype-instance-identifier-ii/14487