# Demographics service **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2005-03-02 13:37 UTC **Views:** 39 **Replies:** 48 **URL:** https://discourse.openehr.org/t/demographics-service/14481 --- ## Post #1 by @Yin_Su_Lim This discussion document is produced by UCL \(CHIME\) to highlight issues that have arisen when designing a Demographics Service component\. This service component will need to conform to the openEHR demographics package and be able to support the requirements of live demonstrator sites in north London\. Any feedback and comments are welcome\. --- ## Post #2 by @Gavin_Brelstaff Yin Su Lim wrote: > This discussion document is produced by UCL \(CHIME\) to highlight issues that have arisen when designing a Demographics Service component\. This service component will need to conform to the openEHR demographics package and be able to support the requirements of live demonstrator sites in north London\. Any feedback and comments are welcome\. This is a \_tantalising\_ question \- that I've ruminated on for some time\. First it is not clear why Demographics should be separated out like this from the entire record \- it just introduces potential inconsistency due to replication issues or worse mis\-identification of a patient\. From an evidence\-based perspective, it might be best to send and receive a "sealed network packet" of as much as the patient record as bandwidth permits: That could mean the entire text data \- leaving larger payloads such as exam\-data/imaging/traces etc to be requested on demand\. The receiving medic would then be able to make any decisions on the basis of the best available evidence at that particular time \- using the traditional document metaphor\. Of course the onus is on client\-side to make all evidential aspect of that document visible during any decision making \[no mean task\]\. But surely in an active clinical community the entire patient record cannot be locked out of use while one participant is working on it\. Traditional database/directory locking works against rather than for the collaborative process IMHO\. Sure participants need to be aware of each others concurrent activity on the same record but they must be given both \(1\) the means to communicate with each other to decide if either should go first \(2\) some convenient means to resolve conflicts that would otherwise arise in the patient record due to their individual asynchronous submissions\. This is \_not\_ rollback but is instead a kind of roll\-forward and again the emphasis would be on a smart client \(able to coherently explain conflicts and choices to resolve them at the point of resubmission\) \- rather than smart server\. The flavor should be that of a Wiki while the overall philosophy should be that of evidential audit/logging: who saw what and what they did when they saw it \- for medico\-legal purposes\. Here the entire patient record would be archetyped as a single document in which Demographics was a self\-contained subsection\. If you really needed to you could just replicate that already archetype sub\-section on a Demographics Server \- but that should be a read\-only copy \- the mastercopy being of course that in the full record\. Something like a versioning XML server \(xmlDB,Xindice,OracleXML DB\) might be the way to go\. Just my 2 penceworth --- ## Post #3 by @Ed_Ermini I couldn't agree more\. In fact, I recently suggested that medical records be viewed as having dynamic and static components that should be handled differently in an RFI response to HHS\. My feeling is that things like DOB, sex, and race do not change and can be stored as such\. Other data, such as name, address, phone, and insurance change infrequently, and can be updated often\. Dynamic information like blood pressure and heart rate change instantaneously, presenting different storage challenges\. In order to make an accurate record of a patient encounter, these elements must be combined into a "snapshot" for that time and place\. The EMR should be able to gather these components from several different places to create that snapshot of the patient\. The components themselves can be stored in a variety of locations, determined by the nature of the data and the optimum facility for processing them\. Appropriate security data may vary by data type\. Ed Ermini MD --- ## Post #4 by @lakewood Hi All, Demographics \(characteristics of a population\) is one element of a larger more complex problem which may be labeled 'Patient Categories and Classifications', or simply 'Patient Boxes'\. Conceptualizing the postal annex analogy, the interesting part comes when the available information is processed and placed into a designated box\. All those Patients living at some time within 25 miles of a known toxic waste dump \(important because the Cancer Death Rate spikes in this area\) can be placed in an appropriately labeled box\. All those former military personnel who served in the first gulf war go in another box\. All those who received surgical care at a hospital identified with MRSA into another box, or a box just for that hospital\. How about people who were employed in areas that later were identified as being life\-shortening\. Pick a job site or a residential location \(data supplied upon request\)\. Or perhaps current agriculture workers exposed to chemicals\. BTW: Try obtaining a complete medical record for a Patient from their branch of the military\. A 'Demographics Service component' is an interesting project but my hunch is that my HMO has not signed onto it\. A 'record' transmitted to a local or remote Practitioner should comply with a set of 'necessary' and 'sufficient' tests so that the recipient does not have to dig though unrelated and inappropriate data, and the Patient is permitted to open the Kimono far enough to obtain needed services\. The 'all\-or\-nothing' approach works where all data is relevant and where little data is available\. An 80 year old Patient may have suffient data to derail the practitioner and deflect focus from currently needed treatment\. There are 'levels' of records and within levels there may be varying needs for different Practitioners\. What is 'necessary' and 'sufficient' for each Practitioner? We may be talking about multiple records, e\.g\., my Internal Medicine Practitioner wanted one set of information, the Surgeon wanted another\. Regards\! \-Thomas Clark Gavin Brelstaff wrote: --- ## Post #5 by @christian.heller Hi, > Gavin Brelstaff wrote: > > > First it is not clear why Demographics should be separated out like > > this from the entire record \- it just introduces potential > > inconsistency due to replication issues or worse mis\-identification of > > a patient\. I agree\. In my opinion, the whole EHR should be stored centrally somewhere\. Of course, it may be replicated regularly etc\. > > From an evidence\-based perspective, it might be best to send and > > receive a "sealed network packet" of as much as the patient record as > > bandwidth permits: > > That could mean the entire text data \- leaving larger payloads such as > > exam\-data/imaging/traces etc to be requested on demand\. \[\.\.\] Good idea\! May be not as much as bandwidth permits, but just that extract of information which a special kind of Medical Practitioner \(MP\) needs\. > > But surely in an active clinical community the entire patient record > > cannot be locked out of use while one participant is working on it\. \[\.\.\] What about optimistic locking? If several MPs get different parts \(extracts\) of an EHR, then at checkin their data do not necessarily have to conflict\. > > The flavor should be that of a Wiki while the > > overall philosophy should be that of evidential audit/logging: who saw > > what and what they did when they saw it \- for medico\-legal purposes\. I agree\. > > Here the entire patient record would be archetyped as > > a single document in which Demographics was a self\-contained subsection\. > > If you really needed to you could just replicate that already archetype > > sub\-section on a Demographics Server \- but that should be a read\-only > > copy \- the mastercopy being of course that in the full record\. > > > > Something like a versioning XML server > > \(xmlDB,Xindice,OracleXML DB\) might be the way to go\. I agree\. \[\.\.\] > A 'Demographics Service component' is an interesting project but my > hunch is that my > HMO has not signed onto it\. I think this is just a question of physical distribution, not of the logical "inside" architecture of a software system \(or component\)\. In my opinion, every EHR system should be able to send extracts of an EHR to another system, may it be demographic information or others\. So, one could set up a physical box responsible for sending demographics only, or images only etc\. But the software running on those boxes can be a general one, only that it once creates an EHR extract with demographic\-, and in the other case with imaging information\. > There are 'levels' of records and within levels there may be varying > needs for different > Practitioners\. What is 'necessary' and 'sufficient' for each > Practitioner? We may be > talking about multiple records, e\.g\., my Internal Medicine Practitioner > wanted one set > of information, the Surgeon wanted another\. This is a very good idea\. I didn't think about it this way before\. An EHR software solution could come with several default EHR extract models \-\- comparable to the "Data Transfer Object" \(DTO\) pattern of Martin Fowler: one DTO model for administrative/demographic information, another for an Internal Medicine Practitioner and so on\. Of course, the software system needs to provide the necessary "Translator" models as well\. These are responsible for copying data from the domain model to a DTO and vice versa\. If the Medical Doctors in a certain region want their own special EHR extract models, they can just create them \(together with the corresponding translator models\) on their systems\. As long as both communication partners \(software systems\) know how to translate a certain model, there shouldn't be a problem\. And, of course, the data should preferrably be sent in XML format, may it be the Clinical Document Architecture \(CDA\) or, even better, the free Healthcare Xchange Protocol \(HXP\)\. Just some ideas, Christian --- ## Post #6 by @Sam Christine and Gavin Some misunderstandings appear to have arisen\. As all EHRs are composed of compositions \- it is only necessary to lock a composition for update \- and that will be usurped anyway by the new version\. Demographics are completely separated out \- this is a design feature that has been there for some time and relates to legislation in some jurisdictions \(no identifying information in the clinical data store\) and does aid security\. Further, it makes merging of EHRs very straight forward and allows for different demographic identification at different sites \- without leading to conflict\. I think you will come to see the utility of this approach\. Extracts are for moving information from one EHR store to another \- not for accessing the EHR \- this is done directly with the server \- and the demographics can be handled as you wish behind the scenes\. Archetypes are for discreet, complete reusable concepts \- it is possible to archetype the different RM classes \- but section archetypes will not include entry archetypes \- rather reference them\. The 'chaining' of archetypes into a composition is done at runtime using 'templates'\. These have not been formalised as yet \- but I include an experimental template in XML \(we have a shared tool to do this with ADL soon\) to give you the idea\. The sort of XML this might generate for a BP of 120/80 measured with a wide cuff, an oral temperature of 36\.5 C and pulse with rythm \- for your information \- is also included\. There are 4 archetypes involved \- one for the section \- vital signs, one for BP, one for Pulse and one for Temperature\. The template selects those aspects of these concepts that are required for recording vital signs, and how they will be organised\. The fact that the BP is part of vital signs does not alter its meaning in any way\. The XML schema for openEHR data is not yet finalised, but will be a single schema for all shared information\. At Ocean we optimise this somewhat for internal presistence \- but the in memory representation is always the same and based on the RM\. Just to reinforce \- these artefacts are not produced according to an agreed openEHR specification \- and the standard form of templates will not be XML as in this example \- though you can clearly do as you wish locally \(templates do not alter semantics\)\. I hope this is helpful\. Cheers, Sam Christian Heller wrote: [details="(attachments)"] [Vital_signs_openEHR.xml|attachment](upload://coRxLjO822fzUb8FHQXmVCzzrs6.xml) (11.3 KB) [Vital_signs.template|attachment](upload://fh6lbw2WFd86GjieYpcJiFGUnUf.template) (1.05 KB) [/details] --- ## Post #7 by @Bigpond The EHR is rather a unique document and a layered approach is necessary as old data must never be altered \- may not necessarily be accessible but must never be altered\. Errors can be corrected but the error must remain totally accessible in the manner it was presented to the clinician when it was relied upon \- eg clinical results, medications\. The concept of layering new information on old is important\. There does have to be lock outs or transaction controls when new data is being entered in but there is no need for old material \(old may be seconds of course\)to be locked out cause it can't or shouldn't be changed\. If two doctors are entering elements of say a discharge summary then one cannot edit while another is adding \- it needs a message indicating someone else is working on the current document and wait\. It is more complex than that but the basic principle applies old data never changes even old addresses must stay\. Legally it is important to be able to reproduce exactly the circumstances that the computer presented to the clinician at any point in time for inquests, litigation etc\. We are dealing with these issues today with our CIS and it is a challenge\. David Evans Brisbane Australia --- ## Post #8 by @system Please once more your attention: There is no way, except by use of the OID, for an automated process, to find out which kind of identifier is presented in the extension\. \(As described in TS14796, the assigningAuthority may not be used by an automated process, and the assigningAuthority says nothing about the kind of II, but only about the name of the Authority, which often is a government institution, a healthcareprovider\-name or a company\-name\.\) The OID heavily relies on services which are not yet defined or implemented in many environments in the \(Dutch\) field\. Therefore, the OID is at this moment not useable for me, and I doubt if it will be coming few years in the Netherlands\. What is also important, is that the OID often only will be resolvable when there is a connection to the overall Internet, which not always may be the case\. Therefor, I would welcome if there would be a Qualifier in the II\-object, which defines what kind of identifier is presented in the II\-object\. This qualifier could use a not too long list, for example \- local system ID \- insurance number \- social security number \- \.\.\.\. This would be a blessing for the project on which I am working\. How can I handle this best and efficient? Are there any thoughts about this? Thanks Bert Verhees --- ## Post #9 by @system One more remark/question: Is there an OID which can be used if there is no OID known, f\.e\. 0\.0\.0\.0\.0? I ask this because OID is a mandatory field Thanks Bert Verhees --- ## Post #10 by @system Allow me a ignorant question Is tehere a place where I can download sourcecode from GPIC implementation, to learn from\. The programming language is not important\. Thanks Bert Verhees --- ## Post #11 by @lakewood Hi David, Significant problem\! However, software configuration management has solved this before\. In the Legal or secure OS environments the contributions of individuals are in fact part of the record even through the 'end\-game' is an update that merges the contributions of all, e\.g\., a composite record\. It is critical that 'information' is not lost nor corrupted\. Efforts to 'crunch' multiple records into a satisfactory record usually fail this requirement at some point\. A reasonable objective is to permit multiple Practitioners to enter information simultaneously, maintain original context and content, build a composite record that is compatible with the target record\-handling system, and support 100% re\-assembly of all sources of information\. A 'build\-and\-submit' or 'interactive\-entry' architecture can yield multiple 'composite' records that may also be linked by one or more events, e\.g\., surgery and lab work\. It may also be necessary to declare a higher\-order event \(in a record\) to which subsequent events can be linked \(extra\-record, meaning the event can transcend a collection of records, e\.g\., multiple contacts\-same cause\)\. Information organization is a virtue; lack of it may well impact information retrieval\. Try coordinating the activities and results of 20\+ Software Engineers working on a release\. Things happen in parallel\. The Legal environment in particular requires reconstruction\. Regards\! \-Thomas Clark Bigpond wrote: --- ## Post #12 by @Karsten_Hilbert > The EHR is rather a unique document and a layered approach is necessary as > old data must never be altered \- may not necessarily be accessible but must > never be altered\. Errors can be corrected but the error must remain totally > accessible in the manner it was presented to the clinician when it was > relied upon \- eg clinical results, medications\. That is not feasible as it would amount to taking physical pictures of the screen as it looked when displayed\. And even this would only prove what the user \*might have seen had she tried\* \- certainly not what she \*saw\*\. Karsten --- ## Post #13 by @Sam Karsten You will see from the attestation class that it is possible to add an image with a digital signature \- allowing compositions to be pixelmaps for legal purposes if required\. Cheers, Sam Heard --- ## Post #14 by @Bigpond "That is not feasible" And that's the problem that will keep the technical people in money for years to come\. Not only must it be feasible it will be demanded by judges and courts if the EHR is to ever be truly adopted\. Even now we have rules that all e\-mails where a decision is made must be printed out\! The paperless world has never been to court\. It is feasible of course but complex\. Flags are set when pages are viewed, there are intricate audit trails \(terabytes\)\. The fact that no one is doing it yet is that the litigation costs haven't risen high enough to balance the need to do it\. Once a few specialists are sued for activities that can not be supported by the record and they known they were innocent then we will see some very interesting changes, either a reappearance of paper records \(personal\) or a new paradigm of image capture\. IMHO of course\. David --- ## Post #15 by @Bigpond You speak much sense\!\! "The Legal environment in particular requires reconstruction\." Oh that was the best one I heard today \- it's in the order of when the warp drive emerges\. Need to think more on your wise thoughts though\. David --- ## Post #16 by @Bob_Smith Hello David and Thomas, You said: >> You speak much sense\!\! >> "The Legal environment in particular requires reconstruction\." When you combine these ideas of "Sense Making" and "Reconstructing the legal environment's relationships to medical communities of \_EHR practice" we tickle the need for some common upper ontology for the domains of governance which includes the process by which the legal environments are created and maintained in various countries\. Several of us involved in a US NHIN\_EHR Request for Information process have begun muddling the question of governance in standards bodies such as OASIS and considering the processes by which XML evolved under Jon Bosak and others a decade ago as the basis for building some US Natl Health Info/Knowledge Networks to support standards for \_EHR deployment and use\. So an intenational awareness is essential, but how far has the openEHR community explored these dynamic issues? And how are the relationships being expressed? Bob --- ## Post #17 by @Karsten_Hilbert Sam, > You will see from the attestation class that it is possible to add an > image with a digital signature \- allowing compositions to be pixelmaps > for legal purposes if required\. Well, surely it's technically possible to track images of what was sent to the screen for display\. But does that help any ? They screen may have been obscured for some reason or other at several layers \(software, hardware, physical world\)\. Karsten --- ## Post #18 by @Karsten_Hilbert > "That is not feasible" > > And that's the problem that will keep the technical people in money for > years to come\. I am not a technical person per se\. I am an clinician\. > Not only must it be feasible it will be demanded by judges > and courts Surely, courts and judges have been known to demand and accepts proofs that aren't proofs before\. They'll learn, too, what things need to be taken to mean\. > if the EHR is to ever be truly adopted\. Too pessimistic, IMO\. > Even now we have rules > that all e\-mails where a decision is made must be printed out\! Which is akin to photographing every screen you view\. > The paperless world has never been to court\. In a court one not always has to provide a waterproof trail of evidence\. There is "substantial evidence" \(is that what it's called ?\)\. And there is "demonstration of due course" which adds a lot of weight to what otherwise are simple assertions\. > It is feasible of course but complex\. Flags are set when pages are viewed, Those flags do not document what you want them to document\. Such a flag only documents that it was set\. Everything else is "due course"\. Eg\. if the flag is set "it is reasonable to assume" that it was set by the software the doctor claims to have used\. Also "it is reasonable to assume" that the doctor thus "saw" what that program would display in conjunction with that flag being set\. No hard proof there\. > there are intricate audit trails \(terabytes\)\. The fact that no one is doing it yet Why do you think this is a fact ? Karsten --- ## Post #19 by @system Life is simple\. Once we physicians know what to ask and why\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #20 by @USM_Bish1 > "That is not feasible" > > And that's the problem that will keep the technical people in > money for years to come\. > $$$ Cheers $$$ ;\-\) > Not only must it be feasible it will be demanded by judges and > courts if the EHR is to ever be truly adopted\. Even now we have > rules that all e\-mails where a decision is made must be printed > out\! The paperless world has never been to court\. It is, but a matter of time\. In this case, may take varying amount of time in different countries, but then technology will finally prevail\. Do you recall a few decades ago when ball point pens first made an appearance in the market ? It took some time for banks and courts to accept documents signed in ball pens \! But then, that was a relatively minor thing when compared with a digital transition\. And we have all forgotten \! 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\. Once a fail proof method is evolved, the legal process would gradually yeild\. The value of the signed hard copy is aithenticity, not content\. It is this issue that we need to address\. > It is feasible of course but complex\. Authentication must be ensured in spite of the complexity\. There is no alternate recourse\. > Flags are set when pages are viewed, there are intricate audit > trails \(terabytes\)\. Audit trails of visits are only to ensure read access by authorised agencies\. What is more important is 'write access' authentication, by best means as commensurate with available technology\. No doctor should be in a position to deny that 'this medicine was not prescribed by me' or 'this is not my report' at any stage\. > The fact that no one is doing it yet is that the litigation > costs haven't risen high enough to balance the need to do it\. > Once a few specialists are sued for activities that can not be > supported by the record and they known they were innocent then > we will see some very interesting changes, either a > reappearance of paper records \(personal\) or a new paradigm of > image capture\. IMHO of course\. It would be inappropriate to wait for litigation processes to bring in the change\. The thought process would have to be built in right from scratch, and refined as technology advances\. For a start we could start with password/ paraphrase protected write access, or GPG/ PGP or maybe thumb imprint \.\.\. But then this is an important issue, and you just can't bypass the Law anywhere \.\.\. Dr USM Bish Bangalore --- ## Post #21 by @Karsten_Hilbert > 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 logs\) \- dumps are signed to be authentic by a, say, CMO \- dump hashes are timestamp\-signed by non\-affiliated third   parties \(say, digital notary servers provided by medical   faculties, etc\.\) This is kept for later presentation to a court\. It shows proper care and due course \(we aim at doing this \- and partially already do \- in GnuMed\)\. In a second step writes might not just be tracked but also required to be digitally signed off which would add non\-repudiation to the data in the authenticated dump\. > Audit trails of visits are only to ensure read access by > authorised agencies\. Even that does not really add any value\. IF access occurred it must have occurred with proper credentials \(barring bugs in the software\)\. The question is whether those credentials were abused by someone who wasn't supposed to know them or by someone in the know but who wasn't supposed to access that part of the data\. One study showed a decrease in the latter when "tracking reads" was announced to the regular users\. Karsten --- ## Post #22 by @lakewood Hi David, At the first level your statement re admissibility/inadmissibility of paper versus paperless records is correct, but correct with caveats\. The Rules of Evidence can vary with the Jurisdictions and the perceived need to enter the 'available record' may permit 'other' records to be admitted \(classbook exceptions\)\. This asides, courts may well apply a higher standard upon Healthcare Practitioners, Facilities, Payers and Patients that translates into 'You should have created and maintained this record and therefore you must comply with fewer permitted exceptions'\. Another tack would be the reasoning that: 'You produce lots of legally admissible records and therefore must meet an additional burden to get the Court to admit this one'\. An inadmissible 'record' regardless of form and content can complicate matters\. As for multiple copies, modifications, errors, omissions and unauthenticated records, these can result in 'hair\-pulling' events\. For example, the attorney that drew up a trust formation \(standard form\) document for my parents omitted a single sentence\. This came from a standard for straight off an Internet site\. How the sentence went missing is a mystery\. The fun part came when the interpretations of multiple attorneys were compared\. To avoid having the whole document thrown out by the Court, and the controlling Trust document, an out\-of\-Court settlement was achieved\. Recognize that no one, even the initial Attorney, detected the missing sentence until the end\-of\-life for the Trust approached\. Applying this to Healthcare as an analogy results in the conclusion that 'Doing it right the first time in a legally sufficient manner may avoid bad stuff later'\!\! Other: \-If something crucial shows up on your monitor screen, do a Screen dump to a file and create a time/date stamped archive\. It is a record and a mechanism exists to produce a permanent copy easily reproduced on paper\. \-admissible records that indicate a complete, continuous, correct, accurate, precise process are preferable over those that are incomplete, disconnected, incorrect, inaccurate and/or imprecise\. They make easy targets\. Regards\! \-Thomas Clark Bigpond wrote: --- ## Post #23 by @lakewood Hi Karsten, Comments in text\. Regards\! \-Thomas Clark Karsten Hilbert wrote: >> "That is not feasible" >> >> And that's the problem that will keep the technical people in money for >> years to come\. >>    > > I am not a technical person per se\. I am an clinician\. > >> Not only must it be feasible it will be demanded by judges >> and courts >>    > > Surely, courts and judges have been known to demand and > accepts proofs that aren't proofs before\. They'll learn, too, > what things need to be taken to mean\. > Legal systems tend to be autonomous in the sense that the remainder of society must conform to the laws and Judicial interpretations thereof\. They tend to rely upon prior interpretations and modifications to the law and demand that suggestions for change be substantiated beyond 'some' unpublished standards, e\.g\., genetics is provable since it is consistently reproducible beyond statistical norms while 'Lie Detectors' are still struggling\. Courts are not likely to be interested in learning about EHRs other than how to use them in related cases as evidence that supports or defeats positions\. EHRs supply content, which can be taken out\-of\-context and which suffers from the common maladies, inconsistent, incomplete, etc\. In this way they are very similar to paper records, i\.e\., Taken together, what do they convey to the Court\. Whatever legal problems the Healthcare Industry now has with paper records may remain with EHRs, and some new ones may be created due to the new technology, e\.g\., a paper record can be locked up in your Safe Record Repository, an EHR can be archived on the Internet and available to Hackers\. >> if the EHR is to ever be truly adopted\. >>    > > Too pessimistic, IMO\. > The EHR will be adopted and hopefully Legislatures will make new, appropriate law\. >> Even now we have rules >> that all e\-mails where a decision is made must be printed out\! >>    > > Which is akin to photographing every screen you view\. > If the content is crucial then make a record of it\. >> The paperless world has never been to court\. >>    > > In a court one not always has to provide a waterproof trail of > evidence\. There is "substantial evidence" \(is that what it's > called ?\)\. And there is "demonstration of due course" which > adds a lot of weight to what otherwise are simple assertions\. > Admissible "Substantial evidence" permits inference and deduction while admissible evidence of a "course of conduct" for an individual, an association or an industry can be used for a variety of purposes to 'tip the scales', EHRs may well be viewed as being more 'form' than 'function', i\.e\., the content is similar to that derived from paper records\. >> It is feasible of course but complex\. Flags are set when pages are viewed, >>    > > Those flags do not document what you want them to document\. > Such a flag only documents that it was set\. Everything else is > "due course"\. Eg\. if the flag is set "it is reasonable to > assume" that it was set by the software the doctor claims to > have used\. Also "it is reasonable to assume" that the doctor > thus "saw" what that program would display in conjunction with > that flag being set\. No hard proof there\. > Flags are a problem and can be subject to multiple interpretations\. --- ## Post #24 by @lakewood Hi Gerard, Wish you were right\. Comment: Changes in the legal system can be used to prove the continuing existance of Evolution\. Regards\! \-Thomas Clark Gerard Freriks wrote: --- ## Post #25 by @system TNO, the institute I work for, is of the opinion that the archiving solution is the preferred one\. By the way\. The topic started discussing demographic services\. In general interoperability translates into the need for many shared points of reference\. So for identities of persons as wel\. Since persons are recorded in systems using a set of more or less unique features and since these unique features vary in time, one person will have many digital identities\. This calls for a mechanism that unites all these variations on one theme\. Eg the demographic server\. Gerard \-\- <work> \-\- Gerard Freriks TNO Kwaliteit van Leven Wassenaarseweg 56 Leiden Postbus 2215 2301CE Leiden The Netherlands \+31 71 5181388 \+31 654 792800 --- ## Post #26 by @lakewood Hi Bob, An 'international awareness' must be developed in advance and evolved continuously\. The EHR community is part of the bedrock of future Healthcare policies, procedures and practices\. It must be based on facts and incorporate all available information\. The Legal community requires facts in the form of admissible evidence and information in the form of testimony, inferences, deductions and interpretation\. It renders judgments in accordance with established law and in some cases remedies for parties before the Court\. In the presence of this certainty it makes 'big' mistakes and sometimes loses its way\. As an example, Forensic Science has upset many judgments and caused the restructuring of many policies, procedures and practices\. A complaint often heard is that Forensic Science, and genetics in particular, has in a short time caused more change than years of reasoned thought within the Community\. With jurisdictions releasing prisoners from Death Row for crimes they did not commit to ineffective FDA\-approved drugs, with fatal side effects, for specific conditions being withdrawn change is 'in the air'\. A recent humorous complaint from the bench comments on juries demanding to have Forensic data and analysis prior to deliberations\. It might be that 'fact\-based outcome\-oriented' Healthcare is becoming popular\. "\.\.\. tickle the need for some common upper ontology for the domains of governance which includes the process by which the legal environments are created and maintained in various countries \.\.\. the question of governance in standards bodies \.\.\. \.\.\." This is not an easy task due to the supremacy of the Administrative, Legislative and Judicial branches of governments plus the diversity and number of governments\. The following is a simple example of how technology, science and legal processes can work in one jurisdiction\. BRAIN FINGERPRINTING \*IN THE SUPREME COURT OF IOWA\*\* \*No\. 122 / 01\-0653 Filed February 26, 2003 TERRY J\. HARRINGTON, Appellant vs\. STATE OF IOWA, Apellee http://www.judicial.state.ia.us/supreme/opinions/20030226/01-0653.asp "\.\.\. Upon our review of the record and the arguments of the parties, we conclude \(1\) Harrington’s appeal is timely; \(2\) this action is not time barred; \(3\) Harrington is entitled to relief on the basis of a due process violation; and \(4\) Harrington’s motion for conditional remand is moot\. Accordingly, we reverse the district court judgment, and remand for entry of an order vacating Harrington’s conviction and sentence, and granting him a new trial\. We deny Harrington’s motion for remand on the basis of mootness \.\.\." Brain Fingerprinting Laboratories http://www.brainwavescience.com/Ruled%20Admissable.php "\.\.\. In order to be admissible under the prevailing Daubert standard, the science utilized in a technology is evaluated based on the following four criteria: \(The Iowa courts are not bound by the Daubert criteria used in the federal courts, but they do use them when determining the admissibility of novel scientific evidence\.\)    1\. Has the science been tested?    2\. Has the science been peer reviewed and published?    3\. Is the science accurate?    4\. Is the science well accepted in the scientific community? The judge ruled that Brain Fingerprinting testing met all four of the legal requirements for being admitted as valid scientific evidence\. The ruling stated: "The test is based on a 'P300 effect\.'… "The P300 effect has been studied by psycho\-physiologists…The P300 effect has been recognized for nearly twenty years\. The P300 effect has been subject to testing and peer review in the scientific community\. The consensus in the community of psycho\-physiologists is that the P300 effect is valid \.\.\." This example identifies one approach to modifying existing legal processes\. There are close to 200 countries in the UN and each maintains significant diversity\. An approach taken within the US is based upon a set of 'Model Codes' \(see the Legal Information Institute at: http://www.law.cornell.edu/statutes.html \)\. A recommended approach to addressing Healthcare under the Law, Legal requirements, handling and interpretations of EHRs, and related Legal processes is to: 1\)Expand the Model Codes to cover EHRs 2\)Include appropriate provisions with the EHR standards to build\-in compatibility with the Model Codes 3\)Include processes to handle change\. Separate Legislatures and Judicial systems reference the Model Codes now, i\.e\., When in doubt look at what others have built\. Since Judicial systems interpret the laws that the Legislatures have enacted the opportunity to impact the system to achieve goals for the common good in the shortest time lie with the Model Codes\. At least this approach can be considered foundational\. Regards\! \-Thomas Clark Bob Smith wrote: --- ## Post #27 by @USM_Bish1 \-\-\-\-\-BEGIN PGP SIGNED MESSAGE\-\-\-\-\- Hash: SHA1 > > 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 logs\) > \- dumps are signed to be authentic by a, say, CMO > \- dump hashes are timestamp\-signed by non\-affiliated third >   parties \(say, digital notary servers provided by medical >   faculties, etc\.\) > This is a logical process to start with\. The issue here is acceptance and institution of the 'notary servers' \.\.\. these need to find a place within the system universally\. \[some snipped\] > > > Audit trails of visits are only to ensure read access by > > authorised agencies\. > > Even that does not really add any value\. IF access occurred it > must have occurred with proper credentials \(barring bugs in the > software\)\. Yup, as far as the technical side is concerned, this should be the end point that we need to go for presently \.\.\. > The question is whether those credentials were abused by > someone who wasn't supposed to know them or by someone in the > know but who wasn't supposed to access that part of the data\. > One study showed a decrease in the latter when "tracking reads" > was announced to the regular users\. These are human shortfalls\. The fact is, if a sysadmin is happy to broadcast access passwords to all\-and\-sundry, ultimately, he/ she is to be held responsible\. It is possible to incorporate much more stringent access methods by thumb imprint or pupil signature varification \(and methods yet to come\)\. However, such mathods may not be easily deployable or cost effective\. Just my 2p Bish --- ## Post #28 by @Bigpond International Law now there's a fascinating issue\. We can't even get Australian law to work across 7 states and territories\. We have a good chance with HealthConnect and a strong central drive \(but\.\.\.\.\)\. Goodness knows how the USA will achieve it\. We are all watching the UK NHS experience with interest\. I remember when we were looking at telehealth services across state boundaries and the legal minefield of registration and accreditation let alone litigation\. What interesting times we can observe\! As always it will not be the technical issues that stop \(slow\) us \- mind you archetypes are a challenge \(sorry Sam\) and so is the HL7 RIM\! In any event it will be the human factors that get us in the end \- consumer rights, privacy, professional roles, security, data aggregation and simple fear and stubbornness\. At the end of the day what created the medical record and why? Have we lost sight of its use as a simple and effective knowledge management tool for individual clinicians to work in the way that they wanted too \-flexible to cope with all their individuality and frailties\. This will be the stumbling block as we try, oh so hard to make it a holy grail of health care \- it never was and I doubt it ever will be\. Hey but isn't it fun\! David from Downunder\. --- ## Post #29 by @Karsten_Hilbert > This is a logical process to start with\. The issue here is > acceptance and institution of the 'notary servers' \.\.\. these > need to find a place within the system universally\. It could just as well be served by another entity of trust, say, a bank safe or a real human notary\. Karsten --- ## Post #30 by @Karsten_Hilbert > Since persons are recorded in systems using a set of more or less > unique features and since these unique features vary in time, one > person will have many digital identities\. > This calls for a mechanism that unites all these variations on one > theme\. IOW you want FEBRL\. Karsten --- ## Post #31 by @lakewood 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\! Gerard Freriks wrote: --- ## Post #32 by @system Hi, What is the definition, scope, function of the concept: " demographic server" in the context of OPENEHR? Thomas, Sam, Dipak: HELP\! Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #33 by @lakewood 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: --- ## Post #34 by @lakewood Hi David, Suggest you look at the creating systems for Patient\-centered and controlled Healthcare Records that incorporate portions of the Practitioner created and maintained Healthcare Records\. Regulations and other 'governance' was designed primarily to target Practitioners and the practice of Medicine\. In many cases they are protective\. Much like the 'common law' of ancestral England where the intent was to keep the populated well enough for battle\. Modern regulations, e\.g\., Patient privacy, are designed to keep noses out of the Patient's and their Practitioner's business, e\.g\., Insurance Companies\. However, Patient controlled secure Healthcare Record Systems are apparently different under the law, exception for the companies controlling them, so that, with secure coverage for all transactions, the Patient and Practitioner can maintain their relationship in private\. Even other Healthcare service providers \(e\.g\., labs\) would deal with Patient\-Practitioner provided identification objects\. There seems to be low impact upon the Practitioner while the Patient has to take some additional control over the management of their Healthcare \(e\.g\., responsible for maintaining the records\)\. As a Patient Advocate I have been looking at the Patient's side of the equation and it is not as bleak as one might think\. Even Senior Citizens are becoming computer literate and computer application trainable\. The younger generations are already there\. Could be interesting for 'Down Under' and Remote Medicine in general\. Regards\! \-Thomas Clark Bigpond wrote: --- ## Post #35 by @lakewood Hi Gerard, Some possible applications and sources: 'coronary and stroke event rates in the population' \(project\-oriented\) http://www.ktl.fi/publications/monica/demoqa/demoqa.htm#Discussion Deaths \- lethal Dosage http://www.ohd.hr.state.or.us/chs/pas/ar-tbl-1.pdf UN Statistics http://unstats.un.org/unsd/demographic/sconcerns/disability/disform.asp?studyid=223 Hearing: http://gri.gallaudet.edu/Demographics/factsheet.html Center for Demographic Study http://cds.duke.edu/publications/search/search_results_ALE.htm HIV/AIDS: http://www.dph.sf.ca.us/HIVPrevPlan/HPPC01FnlRpt/ch3p61~1.pdf RAND/HEALTH: http://www.rand.org/health/archive/sociodemographic/ Center for the Advancement of Health: http://www.hbns.org/newsrelease/after8-8-00.cfm Where related to Healthcare demographics the EHRs may have to incorporate the demographics\. Regards\! \-Thomas Clark Gerard Freriks wrote: --- ## Post #36 by @system HI Thomas, Thanks\. I know for certain we \(and possibly OpenEHR\) is using the term 'Demographic server" for other notions\. SO lets wait for the other Thomas to tell us what OpenEHR means\. Gerard \-\- <private> \-\- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands \+31 252 544896 \+31 654 792800 --- ## Post #37 by @sebastian.garde 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@cqu\.edu\.au Ph \+61 \(0\)7 4930 6542 Fax \+61 \(0\)7 4930 9729 http://infocom.cqu.edu.au/hi --- ## Post #38 by @Kerry_Raymond 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 --- ## Post #39 by @Sam 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 --- ## Post #40 by @system 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 \-\- <work> \-\- Gerard Freriks TNO Kwaliteit van Leven Wassenaarseweg 56 Leiden Postbus 2215 2301CE Leiden The Netherlands \+31 71 5181388 \+31 654 792800 --- ## Post #41 by @lakewood Hi Kerry, Historical documents under the American version of English Common Law are admissible after 30 years, and before in some jurisdictions by affidavit from a Custodian\. This can change at any time\. A potential solution, presuming Custodial Affidavit, is entering the record in a Custodial Record that retains originals\. This will provide a Custodial Trail for the records\. Check this out with an appropriate Attorney in practice in your Jurisdiction\. Entering a historical document within an EHR poses a different problem\. Presuming a secure EHR system, the document must be properly authenticated/certified prior to entry and a Custodial Trail maintained until used\. It must be admissible prior to entry into the EHR\. This varies by Jurisdiction and one should check this out with an appropriate attorney\. A caveat would be: Avoid changing Jurisdictions\. Assuming that a historical document in one Jurisdiction would be admissible in another Jurisdiction is tricky\. Back to the appropriate Attorney\! Migrating a Historical Document to an EHR is a good idea for at least the following reasons: 1\)Electronic records are admissible in many Jurisdictions 2\)Secure Healthcare Electronic Records can be handled as other Electronic Records \(e\.g\., bank records\), e\.g\., custom in the industry\. Again one needs the appropriate Attorney to ensure that Healthcare Electronic Records are treated as other Electronic Records\. In your Jurisdiction there may be prior rulings on the admissible of Healthcare records, or similar records\. It may be useful to access the rulings to determine prior case law\. Unfortunately, Legislative Enactment and prior case law will likely vary somewhat among Jurisdictions within a country; they do between countries especially where to source of law differs, e\.g\., English Common Law\. I usually refer to prior case law on Electronic Records used in Banking \(center\-weight\!\)\. Technology and relevant law evolve with time\. Expect and anticipate change\. Regards\! Thomas Clark Kerry Raymond wrote: --- ## Post #42 by @lakewood Hi Sam, Is the indicated sentence correct? Regards\! \-Thomas Clark Sam Heard wrote: > 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\. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 'EHR model' <\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-> 'EHR model' --- ## Post #43 by @lakewood Hi Sebastian, Correct\! The lifetime of a digital signature is some environments is quite short, which is why one gets to change it periodically\. However, for permanent records the digital signature of the creator can remain fixed since the record is fixed\. You are correct re data transmission, but then to Requestor's and Receiver's digital signatures can be used \(again short lifetime\)\. While actively being handled/processed an audit trail is handy\. A Historical Electronic Record in a Court of Law is required to emulate that of say a paper Historical Record\. If the law states 30 years, then make it 30 or change the law\. This is probably not feasible since changing this law that has existed for some time may have to satisfy other requirements that lead to its enactment\. \-Regards\! \-Thomas Clark Sebastian Garde wrote: --- ## Post #44 by @USM_Bish1 lakewood@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 --- ## Post #45 by @Gavin_Brelstaff 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 --- ## Post #46 by @USM_Bish1 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 --- ## Post #47 by @lakewood 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: --- ## Post #48 by @Karsten_Hilbert > 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 --- ## Post #49 by @Sam No \- sorry \- It should read "The Demographic model has quite\.\.\." Sam --- **Canonical:** https://discourse.openehr.org/t/demographics-service/14481 **Original content:** https://discourse.openehr.org/t/demographics-service/14481