Authenticity Issues [was: Re: Demographics service]
Hi, There is another issue with digital signatures in the context of EHRs: Their value decreases over time and with them the value of digitally signed documents as legal evidence. In other words: securely signed documents don't necessarily provide a secure basis for verifying authenticity for the required time-span of EHRs (30 and more years). This is due to the following reasons: - the employed cryptographic algorithms and the keys lose their security qualification in the course of time. (algorithm may found to be insecure, key length may be too short for increased computer power,..) - It cannot be guaranteed that the directories and documents needed for the verification of the underlying certificates are available for 30 years or more. In addition, the use of digital signing procedures is often insecure and information for the subsequent evaluation of the actual security is missing. To achieve high conclusiveness of digitally signed documents and to realize their integration into practical use, the documents complete life cycle ranging from generation of the document, generation of the signature, presentation, communication to (long-time-)archiving and later use have to be taken into account in a comprehensive way. For a truly long-term-solution for EHRs, a solution must be provided for this problem. If you are interested in details, see http://www.archisig.de/english Further, signed data may - of course - not be changed in order to keep electronic signatures valid. But when data has to be exchanged across networks, or in context of systems migration, such changes are inevitably occuring. Trying to avoid this with the help of new standardized and stable data formats contradicts experiences (although openEHR itself might be a solution for this problem). So, procedures are necessary to convert signed documents and preserve their evidence value (legally secure transformation). See http://www.transidok.de/index-en.html for details. Regards, Sebastian Dr Sebastian Garde Faculty of Informatics and Communication Central Queensland University Rockhampton Qld 4702, Australia s.garde at cqu.edu.au Ph +61 (0)7 4930 6542 Fax +61 (0)7 4930 9729 http://infocom.cqu.edu.au/hi -Original Message- From: owner-openehr-techni...@openehr.org [mailto:owner-openehr-technical at openehr.org] On Behalf Of lakewood at copper.net Sent: Monday, 7 March 2005 5:20 AM To: openehr-technical at openehr.org Subject: Re: Authenticity Issues [was: Re: Demographics service] Hi Bish, Periodic and immediate 'Bio' identification would satisfy certain security requirements re authenticity, e.g., official documents (e.g., post surgical release). Your comment re 'thumb imprint', or scan, provides a more secure means of authentication that may be required. Requiring that a 'digital signature' be incorporated within a EHR is a step forward but if all that is required is the presence of a digital signature one can be obtained from multiple sources. As you indicated 'verification of authenticity' is required. Verification, however, can be 'fooled' as well, e.g., where digital signatures are collected in advance into a set of 'secure signatures' the presence of one or more of these signatures within an EHR indicates just that and no more. How is this solved in other fields? 'Bio ID' is one approach, e.g., 'finger and thumb imprint', a digital photo and a voice track, in addition to other digital signatures puts up a much higher wall. I am intrigued by the combination of voice tracks with background syn, e.g., Practitioner and Practitioner + Patient.. An example would be a Hospital Delivery Room (multiple persons) and an automatically generated voice track Properly encrypted the track would be hard to break and/or deny. In other areas similar approaches are available, e.g., encrypted time/date/voice tracks can be integrated into Medical devices and then into EHRs. Side benefits include integration of the time/date into the EHR. A major problem with the photo approach is that some persons become unrecognizable after a 12 hour shift. A problem with ordinary 'digital signatures' is that they can be hacked, patched and the wrong ones, e.g., a reserved place in an EHR for a fixed-length digital signature is bad since one might be able to place another there. Regards! -Thomas Clark USM Bish wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >On Sat, Mar 05, 2005 at 07:34:47PM +0100, Karsten Hilbert wrote: > > >>>The main issue here is varification of authenticity of digital data >>>entry. There must be some mechanism to ensure that every entry >>>placed in the EHR must be authenticated by the signitory, even if the >>>entry is made by a secretary, DEO or transcription- ist. >>> >>> >>A first-step solution might be this: >> >>- writes are tracked (author, timestamp) >>- regular clear-text database dumps are taken (say, twice daily) >> this includes the tracked writes (eg audit
Authenticity Issues [was: Re: Demographics service]
There are undeniably enormous challenges in this area. However, right now, we have a health system that operates off bits of paper augmented with IT here and there. Can we verify the authenticity of a medical record from the 1970s today? Will a paper health record created today be authenticated in 2030? If a doctor receives a medical history on paper and one of the pages has a fold on the corner which causes two pages to be turned instead of one, can we prove in a court today if the doctor did or didn't see the information on the second page? Hey, forensic science isn't that good even on CSI :-) Surely the goal of EHR is to do better than the existing systems in some areas (so there is benefit in choosing EHR), and no worse in others (so there is no significant detriment)? For example, won't some patients have better outcomes because their doctors have access to their past allergic reactions thanks to an EHR, even if we cannot prove in a court whether the information did or didn't get rendered correctly on a computer screen? If we are serious about proving in court "what the doctor saw", I can only suggest that we create a head-mounted device with a camera (positioned at eye level) and microphones positioned at ears and mouth and record every second of the doctor's working life as evidence of what they saw, heard and said. Of course, it cannot prove whether those images and sounds were processed cognitively or not, which is what you need to establish to go from "what the doctor saw/heard" to "what the doctor knew". It is easy to overlook something on a page or on a screen, despite it being in plain view. If people or organisations perceive significant benefit from technology, they will not wait for the technology to be perfected. They will weigh up the risks and benefits and proceed accordingly. As an example, many people used analogue mobile phones for years despite widespread public knowledge that they were not completely secure, but obviously felt that the benefit outweighed the risk, no doubt figuring that nobody would be motivated to eavesdrop on their basically boring conversations. A few people suffered because their conversations were not secure (e.g Prince Charles!) but most people had no adverse experience. This is not to say that we should not try to solve the problems that are being identified, but I doubt the lack of immediate solutions will be a showstopper to many organisations or nations rolling out EHRs if there are other compelling benefits. Kerry, who thinks there is a need for an openehr-societal mailing list for this kind of discussion Dr Kerry Raymond Distinguished Research Leader CRC for Enterprise Distributed Systems Technology University of Queensland 4072 Australia Ph: +61 7 3365 4310, Fax: +61 7 3365 4311, www.dstc.edu.au - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
archetypes and class constraints
If I might ask a rather mundane technical question about archetypes ... Looking at the archetype models, there appears to be no way to enforce that the class to be used for some specific piece of information is exactly that class and not one of its subtypes. For example, what if it is important to have a DVTime used and not a DVPartialTime? Or an ObjectRef that should never an AccessGroupRef or a PartyRef? My feeling is that the class constraint in an archetype needs an additional property "subtypesAllowed" or similar to cater for the two cases. Kerry Dr Kerry Raymond Distinguished Research Leader CRC for Enterprise Distributed Systems Technology University of Queensland 4072 Australia Ph: +61 7 3365 4310, Fax: +61 7 3365 4311, www.dstc.edu.au - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
archetypes and class constraints
Kerry The archetype editor sets this constraint for dv_date_time using a syntax for the purpose. At present the other reference model classes are not available in the same manner - that is they do not impinge directly on the data. Generally, one assumes that in the reference model people will use the actual classes specified. I am sure Tom will have something to say on the matter! Cheers, Sam Heard - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Demographics service
Dear All The openEHR design team have, over many years, decided to separate the demographic information from the EHR data. Advantages are, amongst others: 1. Security - you need access to both sets of data to know about an individual 2. Normalisation - you can find people even though they have moved, changed their name etc 3. Many health environments have developed demographic services which people want to keep. The EHR model has quite different classes than the EHR model - and the archetypes are therefore different. The demographic server in an openEHR environment provides identifying, contact and credentialling information about parties. Hope this is helpful...Sam > Hi, > > What is the definition, scope, function of the concept: > " demographic server" > in the context of OPENEHR? > > Thomas, Sam, Dipak: HELP! > > Gerard > > -- -- > Gerard Freriks, arts > Huigsloterdijk 378 > 2158 LR Buitenkaag > The Netherlands > > +31 252 544896 > +31 654 792800 > On 06 Mar 2005, at 19:50, lakewood at copper.net wrote: > > Hi Gerard, > > My understanding is that demographic services collect, organize and > process the > characteristics of a 'population'. Presuming this, then I am a > member of a large number > of 'populations' regardless of intent. Narrowed to Healthcare the > number of > 'populations' shrinks but not to one. > > Given the fact that modern 'populations' are not 'stationary' it > appears that there are > many of us that can claim or hold membership in multiple Healthcare > 'populations' > which themselves are subject to new additions, e.g., those > genetically sensitive to > drugs of a particlular family. > > Identifying the indiviudal may have to be a separate operation. > Identifying whether the individual > is a member of a 'population', or 'populations's a subsequent task. > > A 'demographic server' is likely to be specific and limited in scope > to address > 'super populations', e.g., persons residing within the boundaries of > a specific geographical > region, e.g., Africa. A 'network' of such server could provide > additional coverage. > > Since one can apply a variety of rules to the specification of an > individual 'population', > the 'rules' become significant especially where the 'rules' are > chosen to affect results, > all Diabetes Patients in the London area. Due to a number of reasons > one may not be able > to claim that London-area Diabetes Patients are the same as those in > other regions, and, of course, that the Healthcare systems are the > same or equivalent. > > Foundational is 'personal identification'. Without it a 'demographic > server' is handicapped. > Hence a good test for the server is a seriously injured person > arriving at a Healthcare > facility unable to communicate with no other form of identification. > > Since there are many other 'issues' and 'factors' important to the > design, development and > deployment of a 'demographic server' one may have to accept > discussions that attempt > to integrate topics. They are valuable R&D efforts are > results-oriented expectations are > very likely to increase quickly. > > Regards! > > -Thomas Clark > > BTW: I tried to avoid bringing 'Public Health' into a discussion > about 'demographic servers'. > That would have been lengthy! > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Authenticity Issues [was: Re: Demographics service]
Hi, It is known for quite some time that digital signatures are not the best solution to encrypt information that has to be archived. For functions like this we need a real person/organisation that provides this archiving function. see by Ross Anderson: http://www.usenix.org/publications/library/proceedings/ec98/ full_papers/anderson/anderson.pdf Gerard -- -- Gerard Freriks TNO Kwaliteit van Leven Wassenaarseweg 56 Leiden Postbus 2215 2301CE Leiden The Netherlands +31 71 5181388 +31 654 792800 On 07 Mar 2005, at 02:02, Sebastian Garde wrote: > Hi, > > There is another issue with digital signatures in the context of EHRs: > Their value decreases over time and with them the value of digitally > signed documents as legal evidence. > In other words: securely signed documents don't necessarily provide a > secure basis for verifying authenticity for the required time-span of > EHRs (30 and more years). > > This is due to the following reasons: > - the employed cryptographic algorithms and the keys lose their > security qualification in the course of time. (algorithm may found to > be > insecure, key length may be too short for increased computer power,..) > - It cannot be guaranteed that the directories and documents needed for > the verification of the underlying certificates are available for 30 > years or more. > > In addition, the use of digital signing procedures is often insecure > and > information for the subsequent evaluation of the actual security is > missing. > To achieve high conclusiveness of digitally signed documents and to > realize their integration into practical use, the documents complete > life cycle ranging from generation of the document, generation of the > signature, presentation, communication to (long-time-)archiving and > later use have to be taken into account in a comprehensive way. > > For a truly long-term-solution for EHRs, a solution must be provided > for > this problem. > If you are interested in details, see http://www.archisig.de/english > > Further, signed data may - of course - not be changed in order to keep > electronic signatures valid. But when data has to be exchanged across > networks, or in context of systems migration, such changes are > inevitably occuring. Trying to avoid this with the help of new > standardized and stable data formats contradicts experiences (although > openEHR itself might be a solution for this problem). > So, procedures are necessary to convert signed documents and preserve > their evidence value (legally secure transformation). See > http://www.transidok.de/index-en.html for details. > > Regards, > Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2674 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050307/1216af1f/attachment.bin>
Demographics service
lakewood at copper.net wrote: > Hi Sam, > > Is the indicated sentence correct? > > Regards! > > -Thomas Clark > >> The EHR model has quite different classes than the EHR model - and >> the archetypes are therefore different. >> > ^^ > > > 'EHR model'<---> 'EHR model' > Looks like a 'slip of the tongue' ... probably what is inferred is the demographic classes vis-a-vis the EHR classes. Just my interpretation Bish - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Authenticity Issues [was: Re: Demographics service]
Kerry Raymond wrote: > There are undeniably enormous challenges in this area. > > However, right now, we have a health system that operates off bits of > paper augmented with IT here and there. Can we verify the authenticity > of a medical record from the 1970s today? Will a paper health record > created today be authenticated in 2030? If a doctor receives a medical > history on paper and one of the pages has a fold on the corner which > causes two pages to be turned instead of one, can we prove in a court > today if the doctor did or didn't see the information on the second > page? Hey, forensic science isn't that good even on CSI :-) > > Surely the goal of EHR is to do better than the existing systems in some > areas (so there is benefit in choosing EHR), and no worse in others (so > there is no significant detriment)? For example, won't some patients > have better outcomes because their doctors have access to their past > allergic reactions thanks to an EHR, even if we cannot prove in a court > whether the information did or didn't get rendered correctly on a > computer screen? > > If we are serious about proving in court "what the doctor saw", I can > only suggest that we create a head-mounted device with a camera > (positioned at eye level) and microphones positioned at ears and mouth > and record every second of the doctor's working life as evidence of what > they saw, heard and said. The point here is not a big-brother forensic approach - but rather one in which the medic cannot deny that they had the opportunity to consult the entire record document [electronic or paper] that arrived on their [virtual or real] desktop - in the state of completeness that it happened to arrive. In that case the medic can carry our their traditional *responsibility* extracting all the relevant details available in that record document - unmonitored. [Of course they might like to call a colleague to check the facts - as they traditionally have done and surely will want to go on doing] The system designer's *responsibiity* is to not make that opportunity more difficult in the case of an electronic document than it is in the case of a paper record. \Gavin - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
OID once more
Two simpel questions, though the answer may be complicated 1) Is there an OID which can be used if there is no OID known, f.e. 0.0.0.0.0 2) I work for a comany which wants to use the insurance-number of a patient for a special goal. It only wants the Insurance-number. What is the best way to present this? Normally, the Insurance-number is a part of the Identity which is a list of II, but the items of that list do not contain meta-information. How can an insurance number be recognized? -- Thanks, thanks, very much Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
OID once more
Dear Bert, As you know, I am not technical enough to respond to you on OID construction, but I wanted you to know that I am sensitive to the OID-heavy nature of 13606 at present, and will look to ways to ease the implementation burden. I suspect your concerns will be shared by many. With best wishes, Dipak Dr Dipak Kalra CHIME University College London - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Authenticity Issues [was: Re: Demographics service]
On Mon, Mar 07, 2005 at 11:02:03AM +1000, Sebastian Garde wrote: > > There is another issue with digital signatures in the context > of EHRs: Their value decreases over time and with them the > value of digitally signed documents as legal evidence. In other > words: securely signed documents don't necessarily provide a > secure basis for verifying authenticity for the required > time-span of EHRs (30 and more years). The longitivity/ validity of a digital signature, specially if distributed would obviously need the requisite revoke cycle. My concept of the 'notary server' is more of a 'backup server' and only to be referenced on a need basis. It is more of a process of data in, in, in and more data in ... with sporadic data reads only by very selective authorities (in official capacity). The keys of the signitory may change with change of office. Since these keys are not for circulation, and for consumption only by few selected people entrusted with the 'notary server' there should not be a problem in holding on to such 'exclusive' key archives (specific for the notary) for ages to come without change. As longs as physical security of the 'keys' are ensured, there should not be much of a requirement of rotation, since each notary signitory is specific for a time and place. Your views on issues of cryptographic algorithm weaknesses are absolutely valid if the keys are to be distributed beyond the confines of the notary server, or 'trusted' agencies ... Data exchanges should be from the regular servers and not from the notary servers, for day to day transactions, and not all transactions would need notary archival. Just my POV ... Bish - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
OID once more
Thanks Dipa, I hope it helps best regards Bert Verhees Op maandag 7 maart 2005 15:06, schreef Dipak Kalra: > Dear Bert, > > As you know, I am not technical enough to respond to you on OID > construction, but I wanted you to know that I am sensitive to the OID-heavy > nature of 13606 at present, and will look to ways to ease the > implementation burden. I suspect your concerns will be shared by many. > > With best wishes, > Dipak > > > Dr Dipak Kalra > CHIME > University College London > > - > 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
Authenticity Issues [was: Re: Demographics service]
Hi Kerry, A Court case in the US involving testimony by a Healthcare Practitioner, whether a party or an Expert Witness', the 'admissible evidence' includes notes, orders, Patient History and other record-oriented evidence. Testimony is in part directed at this 'admissible evidence' but also includes Professional Opinion. A "... a head-mounted device with a camera ... and microphones ..." would add additional information to the body of 'admissible evidence'. A possible concern is the impact upon Court proceedings this additional 'admissible evidence' would have. Before launching an effort to accomplish integration of these additional sensors one might consult appropriate Attorneys and attempt to determine if in fact an improvement is possible. My suggestion is that based upon reported experiments with Courts (includes Juries) and groups of people, all participants viewing the same sequence of events, interpretations often widely. Unambiguous interpretations is a goal. Integrating information within an EHR that supports ambiguous interpretations should be avoided where possible. Regards! -Thomas Clark Kerry Raymond wrote: > There are undeniably enormous challenges in this area. > > However, right now, we have a health system that operates off bits of > paper augmented with IT here and there. Can we verify the authenticity > of a medical record from the 1970s today? Will a paper health record > created today be authenticated in 2030? If a doctor receives a medical > history on paper and one of the pages has a fold on the corner which > causes two pages to be turned instead of one, can we prove in a court > today if the doctor did or didn't see the information on the second > page? Hey, forensic science isn't that good even on CSI :-) > > Surely the goal of EHR is to do better than the existing systems in > some areas (so there is benefit in choosing EHR), and no worse in > others (so there is no significant detriment)? For example, won't some > patients have better outcomes because their doctors have access to > their past allergic reactions thanks to an EHR, even if we cannot > prove in a court whether the information did or didn't get rendered > correctly on a computer screen? > > If we are serious about proving in court "what the doctor saw", I can > only suggest that we create a head-mounted device with a camera > (positioned at eye level) and microphones positioned at ears and > mouth and record every second of the doctor's working life as evidence > of what they saw, heard and said. Of course, it cannot prove whether > those images and sounds were processed cognitively or not, which is > what you need to establish to go from "what the doctor saw/heard" to > "what the doctor knew". It is easy to overlook something on a page or > on a screen, despite it being in plain view. > > If people or organisations perceive significant benefit from > technology, they will not wait for the technology to be perfected. > They will weigh up the risks and benefits and proceed accordingly. As > an example, many people used analogue mobile phones for years despite > widespread public knowledge that they were not completely secure, but > obviously felt that the benefit outweighed the risk, no doubt figuring > that nobody would be motivated to eavesdrop on their basically boring > conversations. A few people suffered because their conversations were > not secure (e.g Prince Charles!) but most people had no adverse > experience. > > This is not to say that we should not try to solve the problems that > are being identified, but I doubt the lack of immediate solutions will > be a showstopper to many organisations or nations rolling out EHRs if > there are other compelling benefits. > > Kerry, who thinks there is a need for an openehr-societal mailing list > for this kind of discussion > > Dr Kerry Raymond > Distinguished Research Leader > CRC for Enterprise Distributed Systems Technology > University of Queensland 4072 Australia > Ph: +61 7 3365 4310, Fax: +61 7 3365 4311, www.dstc.edu.au > > > > > > > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype editor status
Dear all, there is an anomaly in the openEHR software as of Friday. The ADL reference parser, archetype workbench, and archetype valdiator have been rebuilt with small improvements to the dADL handling code, and with corrected handling of paths, which now must commence with a '/' in all cases. The archetypes have also been upgraded. All of these changes are in the usual places on the openEHR website. Unfortunately, there is a small problem in the Ocean Archetype Editor when it was rebuilt with the changes, which we have yet to resolve. Any current version of this editor, including any version you download today from the OceanInformatics.biz website WILL NOT WORK with the current archetypes, and should not be used. Normally such a problem would have been corrected instantly, but right now, many of us are stretched to the limit with other work, in particular FP6 EU project proposals in Europe, which have a deadline of Mar 22. We expect to have the problem righted in a day or two, at which point a new version will be announced. Apologies for any inconvenience, and thanks for your understanding. - thomas beale -- ___ Research Fellow, University College London (http://www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org) CTO Ocean Informatics (http://www.OceanInformatics.biz) - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
archetypes and class constraints
Kerry Raymond wrote: > If I might ask a rather mundane technical question about archetypes ... > > Looking at the archetype models, there appears to be no way to enforce > that the class to be used for some specific piece of information is > exactly that class and not one of its subtypes. For example, what if > it is important to have a DVTime used and not a DVPartialTime? Or an > ObjectRef that should never an AccessGroupRef or a PartyRef? > > My feeling is that the class constraint in an archetype needs an > additional property "subtypesAllowed" or similar to cater for the two > cases. Hi Kerry, there are two ways to see this. The orthodox oo modelling approach is to say: if your model defines X (concrete) as a subtype of Y (also concrete) then at runtime, an X is always acceptable in a variable of type Y. By this argument, archetypes should not try to circumvent this. If on the other hand, there are circumsances where a Y is ok but not an X, then the underlying reference model should say so by modelling X and Y as disjoint subtypes of a common parent W. A pragmatic approach would be to do what you say. We could probably argue for this just on the basis of the fact that many reference models (i.e. object models) are not well constructed, and out of the control of the archetype designers, and/or that models consdered good today are shown up later on by changing requirements, which changes the validity of inheritances such as the one Kerry points out. The purist in me says stick with the first way of seeing it; the realist says to consider the second. What do others think? - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Archetype editor status
Thomas Beale wrote: > > Dear all, > > there is an anomaly in the openEHR software as of Friday. The ADL > reference parser, archetype workbench, and archetype valdiator have > been rebuilt with small improvements to the dADL handling code, and > with corrected handling of paths, which now must commence with a '/' > in all cases. The archetypes have also been upgraded. All of these > changes are in the usual places on the openEHR website. > > Unfortunately, there is a small problem in the Ocean Archetype Editor > when it was rebuilt with the changes, which we have yet to resolve. > Any current version of this editor, including any version you download > today from the OceanInformatics.biz website WILL NOT WORK with the > current archetypes, and should not be used. Normally such a problem > would have been corrected instantly, but right now, many of us are > stretched to the limit with other work, in particular FP6 EU project > proposals in Europe, which have a deadline of Mar 22. > > We expect to have the problem righted in a day or two, at which point > a new version will be announced. Apologies for any inconvenience, and > thanks for your understanding. I should also mention that a .zip of the latest java-wrapped ADL parser will be available in a day or two. Sorry for the inconvenience. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
OID once more
Bert Verhees wrote: >Two simpel questions, though the answer may be complicated > >1) Is there an OID which can be used if there is no OID known, f.e. 0.0.0.0.0 > >2) I work for a comany which wants to use the insurance-number of a patient >for a special goal. It only wants the Insurance-number. >What is the best way to present this? >Normally, the Insurance-number is a part of the Identity which is a list of >II, but the items of that list do not contain meta-information. How can an >insurance number be recognized? > > for what it is worth, I think that HL7 has not modelled identities properly; using only II for everything assumes that every organisation in the world will have OIDs and be using them for all the things they issue. I really doubt that this will ever happen, but even if it does, it won't be in place for another 10-20 years. In openEHR we differentiate between OBJECT_ID (ids for informational things) and DV_IDENTIFIER, a data type for identifiers of real world obejcts, like drivers licenses and insurance; this latter type contains the attributes you need to indicate the organisation etc.See the data types at http://www.openehr.org/repositories/spec-dev/latest/publishing/architecture/reference_model/data_types/data_types_im.pdf. - thomas -- ___ Research Fellow, University College London (http://www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org) CTO Ocean Informatics (http://www.OceanInformatics.biz) - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Problem with Datatype: Instance Identifier (II)
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 at openehr.org
Problem with Datatype: Instance Identifier (II)
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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
archetypes and class constraints
I vote for the pragmatic approach when we don't control the reference model > >> A pragmatic approach would be to do what you say. We could probably >> argue for this just on the basis of the fact that many reference >> models (i.e. object models) are not well constructed, and out of the >> control of the archetype designers, and/or that models consdered good >> today are shown up later on by changing requirements, which changes >> the validity of inheritances such as the one Kerry points out. > > Yes, that's the angle I'm coming from (where we don't control the > reference model). > > And in any case, I don't see the openEHR following the purist road of > having FullySpecifiedDateTime or > ObjectIdThatIsntArchetypeIdNorTerminologyIdEtc :-) -- Carl Mattocks co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC co-Chair OASIS Business Centric Methodology TC CEO CHECKMi v/f (usa) 908 322 8715 www.CHECKMi.com Semantically Smart Compendiums [AOL] IM CarlCHECKMi - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Authenticity Issues [was: Re: Demographics service]
> However, right now, we have a health system that operates off bits of > paper augmented with IT here and there. ... > Surely the goal of EHR is to do better than the existing systems in some > areas (so there is benefit in choosing EHR), and no worse in others (so > there is no significant detriment)? Well spoken. This practical sentiment is exactly why I pointed out where it leads to worry too much about having perfect security instead of focussing on patient and provider benefit. > If we are serious about proving in court "what the doctor saw", I can > only suggest that we create a head-mounted device with a camera > (positioned at eye level) and microphones positioned at ears and mouth > and record every second of the doctor's working life as evidence of what > they saw, heard and said. And this is what it would lead to. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
