Op woensdag 2 maart 2005 14:11, schreef u: > 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 > > Regards, > > Isabel Rom?n > > ----- Original Message ----- > > From: "Bert Verhees" <bert.verhees at rosa.nl> > To: <openehr-technical at openehr.org> > Sent: Tuesday, March 01, 2005 10:30 PM > Subject: Re: Problem with Datatype: Instance Identifier (II) > > > 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. > > > > --------------------------------------------- > > > > > 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? > > > > 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. > > > > Regards > > Bert Verhees > > > > - > > If you have any questions about using this list, > > please send a message to d.lloyd at openehr.org -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
