Re: Syntax for including archetypes in SLOTs, regardless of version
On Tue, Dec 18, 2018 at 01:17:38PM +0100, Karsten Hilbert wrote:
> > In other words, add a pattern to catch “any single (possibly double) digit
> > version number” (?).
>
> \d{1,2}
Ah, sorry, was misled by *number*.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Syntax for including archetypes in SLOTs, regardless of version
On Tue, Dec 18, 2018 at 12:09:56PM +, Bakke, Silje Ljosland wrote:
> In other words, add a pattern to catch “any single (possibly double) digit
> version number” (?).
\d{1,2}
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Aw: Re: Generic modeling and issues for querying
> openEHR data representation and querying are founded upon this > fundamental principle - store how you like, query how you like. OK, as long as "store how you like" does not impede "query how you like", the principle seems reasonable. Karsten ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: GDPR and OpenEhr.
On Mon, Sep 03, 2018 at 03:19:04PM +0200, Bert Verhees wrote: > Karsten, you are right, a clinician, in the most countries is obliged to > keep an EHR. But the law does mostly not say he must keep it at his own > office. So if it is kept at Google or Microsoft, or some smaller PHR > provider, I think this is fine according to the law, but still some > law-changes may be needed. I think we agree. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: GDPR and OpenEhr.
On Mon, Sep 03, 2018 at 01:08:41PM +0200, Bert Verhees wrote: > So, on medico-legal purposes as Ian and Karsten and maybe others referred > to, a patient, if he maintains his own PHR, and he likes to delete it, he > can never sue a clinician, because, he, himself, destroyed important > evidence. That is certainly not true, and also not what I intended to say. > For that reason, it is for a clinician not necessary to maintain > data-copies from the patient What ? Even sub-legal practice law mandates keeping a record :-) I am sure I misunderstand what you are saying. > If the clinician needs access to the data, for example, to prepare for a > visit next day, he can ask the patient to allow access to the PHR the day > before the visit, but these are al infrastructural details, for which > solutions can be found. Not in the real world today. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: AQL on specific list of compositions
On Sun, Sep 02, 2018 at 10:25:23AM +0100, Ian McNicoll wrote: > Very helpful. I'd suggest one other minor tweak to differentiate 'episode' > which is one or more encounters associated with a particular problem or > issue, and 'period of care' which is administrative idea that > roughly equates to an admission or series of outpatient appointments. In > hospital care the two are often conflated. Agreed. Since GNUmed does not concern itself with documenting in-patient care it never occurred to us that the time in hospital most certainly does not necessarily equate to an episode :-) Particularly since GNUmed affords documenting hospital stays (with admission and discharge dates), each stay linked to episodes of care. Thanks for pointing that out. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: GDPR and OpenEhr.
On Sat, Sep 01, 2018 at 08:33:08PM +0200, Diego Boscá wrote: > Supporting hard delete doesn't mean mandate hard delete :) Indeed. I agree with that. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: GDPR and OpenEhr.
On Sat, Sep 01, 2018 at 08:29:33PM +0200, Diego Boscá wrote: > There is in fact that right, the "right to be forgotten" > https://gdpr-info.eu/art-17-gdpr/ > The requirement you say about Germany is backed by sections 3 (b) and (c) > These exceptions do not apply to private providers, so we have the legal > need to support that kind of delete operations to allow openEHR systems to > be GDPR compliant Whether we like it or not (I do not like it, personally, as a patient, but do like it, professionally, as a GP): in Germany there is the right to keep a record "as long as there is suspicion you might be sued such that you can exercise your right to defend yourself". 30 years is the latest you can be sued in Germany. So that's when a hard delete can be requested (arguably it even becomes mandatory). Period. However, the provider is legally bound to make sure the record is not used after the patient requests that (there's other time limits for other things, but that's the most a patient can *request* after those other deadlines have passed and before 30 years are over). It doesn't matter what anyone thinks. That is the legal situation ATM. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: GDPR and OpenEhr.
On Sat, Sep 01, 2018 at 07:57:31PM +0200, Diego Boscá wrote: > If a patient uses a private health provider then he has the right of taking > all that information and move to another provider. In that case he will > want a hard-delete of data. Indeed they will want that, but there is no absolute right for a hard-delete (not that I personally like that fact). As I said, in Germany, that right currently only takes effect after 30 years (that absolute right). In the meantime, however, there's a right for sealing against access. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: AQL on specific list of compositions
Thomas, sorry for the late reply. > Out of interest, is there a diagram or other GNUmed documentation / > explanation of all this. It's pretty close to what I think openEHR is or > should be doing; you have formalised more of this than we have so far, so > it's good to have some reference points available. Some details are in my head, but the big picture on the Wiki, say, in the User Guide: http://wiki.gnumed.de/bin/view/Gnumed/GmManualBasicEmrConcept The reason this aligns fairly well with the thinking in OpenEHR is that I've been following this list for far too long :-) Regards, Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: GDPR and OpenEhr.
On Sat, Sep 01, 2018 at 06:24:22PM +0100, Ian McNicoll wrote: > There are certainly some implementations that allow for hard-deletes of > compositions and Ehrs. This is a complex area as GDPR does not confer an > absolute right for medical info to be forgotten (as I understand it). It > does allow for copies of the record to be retained for medico-legal > purposes. The latter reason for retention would have a hard limit of 30 years in Germany. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: AQL on specific list of compositions
On Mon, Aug 20, 2018 at 10:04:45AM +0100, Thomas Beale wrote:
> Some of these Contsys definitions are problematic:
> > ENCOUNTER
> >
> > But there is an encounter when the HcP interacts with the EHR without a
> > Patient (Virtually) present.
>
> that would certainly be a subversion of the usual meaning of 'encounter'
> (literally 'to meet') in English and all the latin languages at least... (in
> Portuguese and Brazil health system, the word is 'atendimento', i.e.
> attendance... - probably the same in Italian and Spanish).
>
> It would be better ontologically to call such an event something else - in
> openEHR it is a commit of a Contribution.
I agree. In GNUmed we tend to think of this as a "session",
in quite a technical sense, between the technical system and
_a_ ("one"-party, where one is by purpose, not by number) actor.
So, a tumor board meeting is a session, as long as the
patient (or a non-staff guarantor) is not present.
Perhaps it's the difference between ABOUT the patient as
opposed to WITH the patient.
A session is the frame within which the commit of a
Contribution occurs.
An encounter does need a session (implicit or explicit) in
order to technically manifest itself. But a session does not
need an encounter.
Waters get muddy when patient and system are involved only,
due to information asymmetry: What if the patient interacts
with the system and the system is programmed to reinforce
adherence. Patient types into a "Question: ___" GUI
field: "Should I continue this medication ?" And the system
answers:
Generally, you should continue as previously decided.
However, if you see fit to rethink that decision would you
like to:
- leave as is
- revisit the previously documented decision details
- decide something else now
- contact a HcP now
- book an appointment
> I would suggest that most people think an episode of care is not limited to
> one HCP, and is not always limited to one health issue, even if there is
> usually one main 'problem' on admission. An episode of care is usually
> thought of as care to resolve an issue for a patient by a team of HCPs
> working in an integrated environment, e.g. a hospital. If the resolution of
> the issue requires care that crosses institutions (usually the case), then a
> different term is probably needed for that.
In GP land it feels more helpful to think of Episodes of Care
to relate to one "issue", "problem" each. Several episodes -
about currently-thought-to-be-different issues can overlap.
In GNUmed we over-arch episodes of care with "health issues".
Each health issue can have several (non-overlapping) episodes
over time. Each issue can be thought of to have several
episodes (technically) going on at different institutions
concurrently.
Each problem manifests as a thread, an episode of care for
that problem, running through one or several encounters. Each
encounter can interweave several threads. Each problem may
become identified to belong to a particular health issue, an
underlying "cause".
IOW, episodes and encounters are orthogonal in nature.
Problems are the labels of episodes. Health issues are the
containers for potentially several episodes.
At least in GNUmed.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: AQL on specific list of compositions
Hello Gerard, > ISO System of Concepts for Continuity of Care (ContSys) defines all kinds of > concepts related to care and its documentation. I (GNUmed, that is) agree with the definitions you refer to. I was answering to Ian's input: > As Dileep has indicated he probably would use folders if Ethercis supported > them. Another alternative is to create an Encounter ID for each new > encounter (which in Dileep's example, I think I would call an episode of > care, and simply tag each composition with that Encounter ID which seemed to me to equate Encounter with Episode of Care. But I may have misunderstood Dileep's example. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: AQL on specific list of compositions
On Fri, Aug 17, 2018 at 03:36:23PM +0100, Ian McNicoll wrote: > As Dileep has indicated he probably would use folders if Ethercis supported > them. Another alternative is to create an Encounter ID for each new > encounter (which in Dileep's example, I think I would call an episode of > care, and simply tag each composition with that Encounter ID An Encounter (in community medicine) is very much different from an Episode of Care. An Encounter happens when patient and healthcare system "meet" in some way, it is one-off. It can encompass a multitude of Reasons for Encounter, about different care targets. An Episode of Care is a time range during which one particular care target is handled. It manifests itself during 1..many Encounters, each of which is about 1..many care targets (problems). Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Drug dispense entry class question
On Sat, Aug 11, 2018 at 04:24:47PM -0300, Pablo Pazos wrote: > > > I'm inclined to think it as an ACTION if this task alters the state of > > the > > > prescription INSTRUCTION ISM. On this case, as a parallel question, I'm > > not > > > sure if the dispense ACTION should be a final "COMPLETED" state, what > > > happens if we want to record the patient's intake of the drug? Where the > > > real "COMPLETED" is when the treatment is finished. > > > > That might mean that some INSTRUCTIONs never get COMPLETED > > until the patient dies. > > > > > There is a state "EXPIRED", so that is covered IMO if an expiration date is > recorded, or even if the whole system has preconfigured expiration dates > for drug treatments. I meant to say that some treatments will not end until the patient dies meaning that the COMPLETED state will never be reached if we take into account >>> [...] the patient's intake of the drug [... where] the >>> real "COMPLETED" is when the treatment is finished. Regards, Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Drug dispense entry class question
On Sat, Aug 11, 2018 at 04:03:28PM -0300, Pablo Pazos wrote: > How would you map a "pharmacy drug dispense" task, where the patient comes > with a prescription and a clerk delivers the medication packages? > > I was thinking this is clearly and ACTION, but also seems to be an > ADMIN_ENTRY, since it is just a delivery of some product. > > I'm inclined to think it as an ACTION if this task alters the state of the > prescription INSTRUCTION ISM. On this case, as a parallel question, I'm not > sure if the dispense ACTION should be a final "COMPLETED" state, what > happens if we want to record the patient's intake of the drug? Where the > real "COMPLETED" is when the treatment is finished. That might mean that some INSTRUCTIONs never get COMPLETED until the patient dies. It might help to think of shifts in responsibility: who is primarily responsible for completion of a given action ? - write prescription -> doctor - hand out drug based on prescription -> pharmacist - take drug as instructed -> patient Each change of responsibility: doctor -> pharmacist -> patient might warrant a COMPLETED state. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Question about periodic interval events
On Mon, Jun 25, 2018 at 11:17:43PM -0300, Pablo Pazos wrote: > > Any Event (process) has an end date and start date an can be small but > > never zero. > > End dates are always different from start dates. > > So what do you mean? > > I'm talking about openEHR events by the definition of the specs, not trying > to come up with another definition. In openEHR POINT_EVENT is the record of > an event that to the record is just a point in time, doesn't really matters > if in reality the event took 10 seconds to execute, like a BP reading. That > is not clinically relevant in most contexts. So, if you say that it is not clearly defined in the specs > That is not > clearly defined in the specs (going back to my original question). it should a) get defind and b) one would, for current practical purposes, stick to the same moment in time inside each in-event period, be it either start, end, or middle. Given that real-world actions of the same type take variable amounts of time, one would assume the start times to be "more correct" and closer to the intended period than end times. Eventually, the "middle" times distance will be closer to what *actually* happened to the patient. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Question about periodic interval events
On Sat, Jun 23, 2018 at 04:35:36PM -0300, Pablo Pazos wrote: > As usual I'm reading the specs and have a question about periodic interval > events. > > I'm not sure how the period is calculated in a series. Let's say we have > interval events on a time line: > > ---E1.start___E1.end--E2.startE2.end---... > > Note: interval events can have different durations. > > Is the period calculated from E1.start to E2.start or from E1.end to > E2.start? > > This is of course to know when E3 should start. As a doctor I would say it depends on what E is, medically. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?
On Wed, Mar 21, 2018 at 04:32:53PM +0100, GF wrote: > My point is that some times we can not/want not use points > on the time line but use fussier terms like: begin of an > event somewhere in 2015, or a duration of one month, or Which can be modelled as +/- such as +/- <3 months> Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: [Troll] Terminology bindings ... again
On Wed, Mar 14, 2018 at 11:56:07PM +, Mikael Nyström wrote: > Yes, of cause it is! My main point was that a statistical > classification is a simpler product than a clinical ontology > and it is therefore also easier to implement a statistical > classification than a clinical ontology. And it is also dangerous to your health if used for clinical care (never mind that that's mandatory in Germany): If I rule out AIDS in a patient I can - in Germany - attach to the EHR the relevant ICD-10 appended with an "A" for "Ausschluß" (as in "ruled out"). When said patient travels to the United States many people will understandably ignore the "A" (as it has no meaning to them and it does not belong to the core definition of ICD-10), et voila, we've got a manufactured HIV infection. Even more dangerous situations could be construed. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: [Troll] Terminology bindings ... again
On Wed, Mar 14, 2018 at 11:28:28AM +0100, Philippe Ameline wrote: > because MD > keep seeing information systems as "back office" components, also > because they are often individualists very at ease in silos (practice > and specialty)) Practitioners need to be able to control their space for, at a minimum, liability concerns, which are brought about by the amount of implicit trust that is put forword towards them (and then happily withdrawn at the slightest chance of litigation). It is only natural that most MDs will resist "change for no good reason" and be *very* conservative. > and they are still fully organized for acute care (to > put it simply, the medical system is fully upside down and the GP should > become an orchestra conductor (what she often dreams she already is) but > is stuck in the one-man band role). ~70% of _all_ reasons for encounter are fully solvable inside the GP "domain". But that goes counter to what most patients want and believe they need. Which is the biggest obstacle for primary care based healthcare. At least in Germany. "Chronic care" is nothing new, it has been the mainstay of General Practice for, what, centuries ? (not that any noticeable number of IT solutions had fostered that approach so far) > the dynamic team of the > contributors around a given individual). That, of course, is a vision in need of better application. > The most important point to consider here is that, when considering the > person's bubble, it is really mandatory to be plainly holistic, that's > to say to consider health as a project among many other projects > (education, employment, social issues, ordinary life projects, etc). It > is a place where the term "patient" is prohibited. If we remove the term "patient" we will remove the very last trace of what it means to fall ill - to endure, with the necessary patience. Only "clients" remain, believing that healthcare can work like a business process, getting themselves repaired as needed. While I fully support the process of informed shared decision making, and embrace it to the extent possible, 15 years of daily face-to-face encounters with literally many thousands of patients painfully teaches that the majority is not currently able to take matters into their own hands AND live with the consequences. So, yes, let's build systems to be open and to enable caretakers and caregivers, but let's not expect those systems to be used that way by the great majority. Karsten (speaking from a German healthcare perspective only) -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Aw: Re: Re: [Troll] Terminology bindings ... again
There are 3 ways of "coding" that I know of: 1. primary coding (ask clinicians and other clinical users to code directly), 2. secondary coding (users record information, a team of specialists do the coding later), 3. assisted coding (software helps users to code, and there are many ways of doing this, from NLP to GUI wizards). But I'm not sure if Karsten was talking about this, let's wait :) I was mainly talking about the first, which is standard in German ambulatory care. Karsten ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Aw: Re: Re: [Troll] Terminology bindings ... again
>>> just imagine standardizing every diagnosis >> That typically leads to either bad statistics or disimproved care. > Can I ask why? It of course depends on the suitability of the standardization process (as in the applicability of a coding system to the domain - medically and in purpose). It is a problem of up-/downcoding. Standardizing typically needs classifying, the classes of which are either to fine-grained (doctors will pick a diagnoses which seems somewhat similar to what they think it might be, thereby falsifying the apparent accuracy of statistics based on the coding system), or too coarse (the picked diagnosis will be overly broad, thusly not reflecting reality "enough"). I guess what I am saying is that one cannot expect to "just standardize" diagnoses and hope to meaningfully draw conclusions from that post hoc. The standardization process needs to be tied to the question that is going to be asked of the standardized data. Karsten ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Aw: Re: [Troll] Terminology bindings ... again
> just imagine standardizing every diagnosis That typically leads to either bad statistics or disimproved care. Karsten ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Setting thresholds
On Fri, Mar 02, 2018 at 01:48:40PM +, Bakke, Silje Ljosland wrote: > A doctor making and recording a conclusion that a > measurement of some kind is too high or too low, IS a > diagnosis. Uhm, no. > their conclusion would be recorded as a diagnosis of hyponatremia. While most doctors will do that it is wrong. Hyponatremia is not a diagnosis. It is just a supposedly-clever way of saying what the lab already said. It is intended to make non-doctors think we doctors are in control of the situation. At best, it is an unresolved problem. All in all it is a _finding_, or observation, notably out-of-range :-) Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Setting thresholds
On Fri, Mar 02, 2018 at 01:18:03PM +, Bakke, Silje Ljosland wrote: > A query for “all patients that have had high BP according > to the doctor” would the way I see this be a query for “all > patients with an EVALUATION.problem_diagnosis with one of a > defined set of codes for ‘hypertension’ and no resolution > date”. It would not be. Because the two assertions are not equivalent. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Setting thresholds
On Fri, Mar 02, 2018 at 10:55:47AM +, Bakke, Silje Ljosland wrote: > I've hesitated to participate in this discussion, but I think I have a couple > of points to add now, as I think there are two different problems being > discussed here: > > 1. The original problem, which in my opinion is how and where to store > reference ranges for clinical observations such as for instance blood > pressure. These reference ranges are often based on clinical research, and > may change with time as new research emerges. In my opinion these shouldn't > be stored with the original observation data, but can (when needed) be stored > with any interpretation where the data is used to reach a conclusion, for > example a symptom, diagnosis or even just an instruction. The reference > ranges that are current at any point in time however, should be stored and > accessed from a knowledge base outside the EHR, as they don't relate to the > data of a specific patient. However, that knowledge base may well be linked > to specific archetypes and archetype elements to facilitate its usage, for > example to the systolic, diastolic and position elements of the blood > pressure archetype, if the reference ranges vary based on the position of the > patient at the time of measurement. > > 2. The problem of reference ranges that are intricately bound to > specific observations and their methods, such as lab results. These should > be, and are commonly, stored with the observations in the EHR because the > details of analytic method and other factors that affect them are far too > complex to include in the EHR data. The RM attributes "normal_range" and > "other_reference_ranges" (and "normal_status") of the Quantity data type are > well suited for these reference ranges. That about wraps it up. Except that I was of the impression that the original question was more about 2) rather than 1). Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Setting thresholds
On Fri, Mar 02, 2018 at 04:33:32AM -0600, William Archibald wrote: > > The ranges will be different across labs and across types of > > measurement due to "precision available", "reagants used", > > "technology applied", and a variety of other ugly real-world > > factors. Even for the very same LOINC from the very same lab. > > > > I don't think this knowledge should (or can) live in the > > archetype but rather be stored with the data and/or the > > interpretation of the data. > > On one hand - I agree with you whole-heartedly. On the other, it seems as > if you are saying that ultimately the real world is so complex (and has so > many options) that reducing it all to a normalized/modeled/semantic basis > is a fool's errand? Too many ugly "real-world factors" to ever be able to > model in detail? (This may be true - but I am simply asking if that is what > you are intending to declare.) I am not attempting to declare that (though I see how it can be thought to be so :) I am only arguing this particular issue ATM. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Setting thresholds
On Fri, Mar 02, 2018 at 11:23:09AM +0100, Karsten Hilbert wrote: > > Not sure if I fully understand/agree. As knowledge advances, past data > > could be seen under a new light (e.g. some medication was given to a set of > > patients and now we know it has a contraindication with another medication) > > and we could get different results each time we run the query, which is > > exactly what we want > > Sure, but, for medico-legal reasons past data must be > see-able under then-applied rules/constraints/ranges And not only "then-applicable", btw. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Setting thresholds
On Fri, Mar 02, 2018 at 10:07:24AM +0100, David Moner wrote: > You are talking about a future reuse or validation of the data. But what it > was discused here is how to define the reference ranges for any data to > take an action at the moment of data registry. And, as Gerard said, those > references must be stored for future interpretation of the data. Thus, I'm > of the opinion that ideally this should be stored together with the > archetype/templates as it is part of the domain knowledge at that moment. The ranges will be different across labs and across types of measurement due to "precision available", "reagants used", "technology applied", and a variety of other ugly real-world factors. Even for the very same LOINC from the very same lab. I don't think this knowledge should (or can) live in the archetype but rather be stored with the data and/or the interpretation of the data. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Setting thresholds
On Fri, Mar 02, 2018 at 09:47:12AM +0100, Diego Boscá wrote: > Not sure if I fully understand/agree. As knowledge advances, past data > could be seen under a new light (e.g. some medication was given to a set of > patients and now we know it has a contraindication with another medication) > and we could get different results each time we run the query, which is > exactly what we want Sure, but, for medico-legal reasons past data must be see-able under then-applied rules/constraints/ranges as well. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Setting thresholds
On Wed, Feb 28, 2018 at 12:18:24PM +, Jussara Macedo Rötzsch wrote: > Ranges aren’t actually part of the Information model, they are rules for > decision support, and therefore belong to the Application level, like a gdl > based CDS In practice there are still needs to store ranges (with the data): 1) path labs will attach ranges to recommended interpretations those are best stored "with" the result(-interpretation) and, no, it is not sufficient to attach them to the test *type* of a measurement 2) ranges applied by a clinician upon which a conclusion has been made those will often end up as textual part of a SOAP note Think of a patient with warfarin monitoring: The lab will cry foul (if not properly informed) but the clinician is happy when the INR is in the therapeutic range. GNUmed "solves" that by allowing to attach both a "nominal" and a "desired" range to each test result. For what that's worth. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Aw: Re: Re: Blockchain
> You may want to check internet access packages in the Himalayas or Sahara > before you setup shop there Bert ;) As for that, Namche had faster internet than myself at home, last time I checked. Karsten ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Blockchain
On Mon, Nov 13, 2017 at 01:35:01PM +, Thomas Beale wrote: > There may be applications such as 'digital notary' that blockchain might be > useful for, which is a trusted third party notary that accumulates signed > hashes of content transactions to the main EHR; if it is thought that the > EHR was hacked or integrity was in question, the digital notary can be used > to check. There was even a gNotary project in gnu health years ago. It never got any traction so we discontinued that project. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Aw: Re: Scenarios for change type "deleted"
> Restricting the reading, and processing, for use outside the provision of > healthcare or labelling > it as restricted NOT for use in healthcare are two alternatives for ‘Logical > Deleting’. Sure. But. What isn't there can't be breached. What is, will be. Karsten ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Scenarios for change type "deleted"
On Tue, Nov 07, 2017 at 10:51:42AM +0100, GF wrote: > c- When patients demand the removal of all data the Patient > record is declared in-active or its Access Control List is > changed such that only the patient has controlling access > rights. Given the fact that ACLs are ephemereal in many sorts of ways I can easily understand the desire for physical deletion (but I agree with you that it is next to impossible under many circumstances). Best, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Scenarios for change type "deleted"
On Mon, Nov 06, 2017 at 11:57:28AM +0100, GF wrote: > Small example. > > As GP I had scanned early 1990’s to CD’s all ‘Green cards’, meaning patient > records. > I can not remove these files on write-only media. Oh, you can, but it is not feasible: Re-read all CDs, delete from recovered data any data that needs to be deleted, destroy old CDs, burn new CDs. > Logical deletion is possible at best. > Logical deletion means that that data no longer is actively used in health > care provision processes. > Absolute and full Physical deletion many times is impossible, or not > practical. Exactly, the latter. An example for *you* are unable (as opposed to *it* is not possible): Your CDs were handed over to a data keeping company to which you don't have access (say, it went bankrupt). Under German law you might well be responsible for a) having made sure that company complies with German law, and b) you may *still* potentially be liable today. Case in point: under German law when a doctor's children inherit (!) patient charts hey automatically become the legally responsible custodians of the records and become, among other obligations, liable to litigations for privacy breaches both by the parent they inherited from and also themselves ! Yes, *non-doctors* may fall under doctor-patient privacy laws just because they become heirs to a former GP office's patient charts... I doubt any such crazy thing is possible anywhere else. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Scenarios for change type "deleted"
On Mon, Nov 06, 2017 at 11:38:23AM +0100, GF wrote: > 2- Physical deletion is NOT ... ... easy and often practically next to impossible. > possible. During the life cycle > of data data collections are backed-up. This can be in write > once, read many times, media. Sometimes complete databases > are replicated as back-up. While true it draws blank stares from legal or political. So we need to declare "deleted" to mean "deleted-as-much-as-possible". Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Re: Re: Scenarios for change type "deleted"
Hi Birger, as a GP in Germany I know what you are talking about :) > b) Implementing such a process was demanded by the state data protection > commissioner. I'm not sure how realistic this would be, but such a network > heavily relies on patients' trust. If there is doubt, you lose. Assuming a patient intends to sue the network it would have had the right to retain any patient data it needed for legal proceedings, regardless of whether the patient requested deletion. Say, to prove a given document arrived in the repository at a given time or was passed on at another given time or some such. > If a patient > withdraws, we don't have any purpose to keep this 'secondary use data' within > the data warehouse/openEHR system. Except for: see above. > For operative systems, this is a whole different story. I recently was told > that physically deleting records should not be possible when you want your > software to be certified as a medical product according to German law. I know :-) and that is quite contrary to what the BDSG demands, so German law contradicts German law. However, the no-deletion policy is pretty much a scare tactics (by over-interpretation) used by German EHR/document archive vendors desiring to sell their "solutions" to German doctors... Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Re: Scenarios for change type "deleted"
On Sun, Nov 05, 2017 at 05:31:50PM +0100, Birger Haarbrandt wrote: > just a short remark: we were involved in a regional EHR (in the sense of a > health information exchange network) project in the state of Lower-Saxony, > Germany. While this might be a different use case, we clearly had to be able > to > physically delete patient data from all IHE XDS repos and registries in the > case of a patient's withdrawal. a) The repositories were likely not the primary repositories intended for immediate clinical care ? in which case the deadlines don't apply b) had you suspected that a withdrawing patient intends to sue the health information exchange network you would likely have had the right to retain data regardless But, yeah, physical deletion certainly seems necessary even if only, say, 50 years post mortem ... Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Scenarios for change type "deleted"
On Sun, Nov 05, 2017 at 03:12:20PM +, Bert Verhees wrote: > In the Netherlands as in many countries, if you change GP a patient is able > to lose his medical history if he wants that. It is up to the patient to > hand it over to the new GP. > > And after 15 years he can demand his previous GP to remove his records. > From that point on all his medical history has gone. The deadlines are different, and they are different for different "types" of medical data, and also for different age groups of the patient, but essentially this is what it's like in Germany as well. Even more so, once a deadline has passed, providers would actually be obliged to pro-actively delete old data (likely even from records of active patients) unless they deem it necessary for either legal self-protection or for continued care. No need for the patient to demand deletion. However, nearly no one does that (pro-active deletion). Karsten -- ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: openEHR-technical Digest, Vol 64, Issue 6
On Mon, Jun 05, 2017 at 05:54:49PM +0100, Thomas Beale wrote: > With 'true' questionnaires, the questions can be nearly anything. For > example, my local GP clinical has a first time patient questionnaire > containing the question 'have you ever had heart trouble?'. It's pretty > clear that many different answers are possible for the same physical facts > (in my case, occasional arrhythmia with ventricular ectopics whose onset is > caused by stress, caffeine etc; do I answer 'yes'? - maybe, since I had this > diagnosed by the NHS, or maybe 'no', if I think they are only talking about > heart attacks etc). And, in fact, the GP may not actually be interested that much in whether you actually really had any (clinical) *heart* trouble. After all, quite a few people will list their esophageal burns or intercostal nerve irritations (which is NOT a problem !). What a GP may be after is likely your internal model of your state of health... Large swathes of Primary Care have needs way different from the more restricted areas of health management. Regards, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Better approach for announcements, forums?
On Fri, Dec 30, 2016 at 11:03:51PM +1100, Klaus Veil wrote: > Agree with Karsten. > > "Push" communications (eg e-mail) are much more effective at reaching people > than "Pull" communications (web sites forums, etc.) > > I have seen the "views"/"eyeballs" drop off significantly when communities > move to forums such as Discourse... in particular the "views" of those who > are not so active in these communities. They indeed don't have the > motivation to go browsing. > > As all research in internet marketing will tell you, e-mail is the most > effective way of reaching people. While I am not in the least interested in being marketed to the technical points are exactly what I am trying to point out. I do agree forums earn bonus points in providing a more visually appealing archive. And they exhibit a greater tendency of getting hacked for diverting credentials. Regards, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Better approach for announcements, forums?
On Fri, Dec 30, 2016 at 12:31:26PM +0100, Diego Boscá wrote: > I'm pretty sure discord can notify you by email of every post or even > mention you have in your subscribed channels Sure. But then I still have to _go_ and read the post. With a list the notify IS the post. And I can't archive posts (say, by topic), entirely delete posts, read posts offline, ... (Note that I am mainly talking about the established lists, as Pekka seemed to be suggesting moving to an all-forum approach -- for announcements, a forum may be fine.) Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Better approach for announcements, forums?
On Fri, Dec 30, 2016 at 12:16:25PM +0200, Pekka Pesola wrote: > I agree - moving to some kind of a forum would in overall work much better > than mailing lists. Certainly not. Lists are get/select, forums are go/browse. Many people don't have time to waste for going browsing. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: UCUM code in body temperature archetype
On Wed, May 18, 2016 at 02:12:39PM +0200, Diego Boscá wrote: > You are right, but not my main point ;) Actually, it sort of is. It shows that the same symbol can mean different things to different people :-) Karsten > 2016-05-18 14:10 GMT+02:00 Karsten Hilbert <karsten.hilb...@gmx.net>: > > On Wed, May 18, 2016 at 01:56:00PM +0200, Diego Boscá wrote: > > > >> If you have a human-readable form for 'º' as "degree" > > > > That's the "o" in "numero", as in Nº, not degree (which is °). -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: UCUM code in body temperature archetype
On Wed, May 18, 2016 at 01:56:00PM +0200, Diego Boscá wrote: > If you have a human-readable form for 'º' as "degree" That's the "o" in "numero", as in Nº, not degree (which is °). https://en.wikipedia.org/wiki/Numero_sign Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Aw: Re: Archetype relational mapping - a practical openEHR persistence solution
> If a database has a field-type XML, then I expect it does something special > with > that field that justifies the fieldtypename. Oh, it does, it offers validation of the XML, AFAICT. Karsten Hilbert ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Archetype relational mapping - a practical openEHR persistence solution
On Sun, Feb 14, 2016 at 12:01:55PM +0100, Bert Verhees wrote: > I don't believe that XML-databases actually store XML. Oracle, for example, > breaks it up in a relational structure. But I don't know the internals of > others well. The worst solution, however for storing XML would be really > storing XML. For what it is worth, here is what PostgreSQL does by default: http://www.postgresql.org/docs/current/static/datatype-xml.html Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
CRUD Restlet
On Sat, Jan 17, 2015 at 11:37:52AM +0100, Diego Bosc? wrote:
The thing is that as long as a code is returned, you know that the
server is up and has given you a response based on your request. By
the code you can tell you more things.
2xx messages tell you that the request was a success
4xx messages tell you that there was a client error
5xx messages tell you that there was a server error
On your example 404 is correct because your client requested to delete
an non existing resource, which is a client error.
What would be the error code for when the client attempts to
call a non-existing service on the server ?
For example: DELET /demographics/party/{partyId}
or
For example: DELETE /demographics/pardy/{partyId}
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
AQL with Demographics
On Fri, Jan 16, 2015 at 12:44:24AM +, Thomas Beale wrote: the first question is: is the patient sex and location stored in the EHR in the system? If so, it's just standard EHR-based query. I'm assuming that the location / address is not however. So a normal query can be written to do everything except the 'living in Alkmaar' bit. That's exactly the boundary between systems built for medical care vs built for epidemiology. Both may have requirements that are contrary to each other, such as this: That last item will need a traversal of the reference PARTY_PROXY.external_ref http://www.openehr.org/local/releases/1.0.1/uml/Browsable/_9_5_1_76d0249_1140169202660_257304_813Report.html, if you have it set. But you might not have it set - we don't in most of our systems, due to privacy / security. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
On Fri, Nov 28, 2014 at 10:55:31AM +, Thomas Beale wrote: in reality GPs sometimes prescribe without a diagnosis as such In reality GPs (I am one) _often_ prescribe without a _diagnosis_. The proverb The Gods put the Diagnosis before any Treatment doesn't hold in GP land. However, GPs (better) never prescribe without a _reason_. That reason very much is the patient problem at hand. There is _always_ a reason for which to prescribe. (if the reason _isn't_ the patient problem the patient may need another GP ;-) If there doesn't appear to be a reason clinicians better think again. administer drugs in hospital without always having an order. And of course historical records of such events can easily be incomplete, making it impossible to reconstruct data from a legacy EHR into the new required form. While that seems like an excellent technical argument the very nature of having documented (generated by import from legacy data), say: reason = unknown / don't know / old stuff - drug 1 - order 2 - lab test 3 tells the clinician to think things over when needed and re-arrange. Of course, one might say that it behooves the system displaying such data to flag unlinked artifacts in the above way. This Danish work was conceptually very good, but a bit naive Are there links ? Thanks. , and we learned from that - provide appropriate information types, and make it possible to have process links but don't require them. From a technical point of view it is probably very prudent to not _require_ such links (as in, say, a non-nullable foreign key) but the user-facing side of the system as a whole (as long as it is used for individual-patient care rather then epidemiology) should make it, like, real hard to forego such links. I suppose I can agree with that approach. All in all this starts to remind me of whether NULLs should be allowed to happen in a given relational schema or whether any such schema should be further normalized to not require NULLs, right ? Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
On Wed, Nov 26, 2014 at 08:52:28AM +, Koray Atalag wrote: Another point is, although I haven't been practicing Medicine for too long now, I know the links between problems vs goals vs actions do not play nicely at all times - indeed for most of the time. They can be subjective and quite error prone. Therefore I don't think 'natural order' (as in DMBS) of an EHR cannot be of POMR type - it has to follow real life: randomness and episodicity. Problem orientation is -- of course -- a best-effort approach. An EHR which forces problem orientation facilitates good care by making clinicians think about what things really mean. What is meant by randomness ? Episodicity does not at all run counter to problem orientation. Karsten Hilbert -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
On Tue, Nov 25, 2014 at 07:01:50AM +, Bj?rn N?ss wrote: To administer this plan you need a dashboard with functionality to filter on overdue, finished, What you seem to be describing is a TODO list to do with solving of pressing issues and is, at best, _part_ of a care plan (in the form of planned repeat procedures, say). A short-term plan (handling AMI, gall-bladder removal, ...) is a protocol rather than a relevant care plan (feel well with diabetes, improve management of factors contributing to risk of depression, sanely approach cardiovascular risk management). Patient-centric care plans better concern themselves with long-term holistic goals in terms of salutogenesis. Karsten Hilbert -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
On Wed, Nov 19, 2014 at 02:42:57PM +, Thomas Beale wrote: Consider: the proof that something really is considered a 'problem', out of all the non-problems and trivial problems (e.g. one-off throat infection) is that some clinical professional wants to create a care plan, to define ongoing treatment and track interventions (all medications, other interventions etc). While I agree that that's something to consider I am creating care plans all day, for both complex and trivial problems. It is very much in the eye of the beholder what's trivial and what's not. My patients are so much the happier for their plan for one-off throat infection. well that's my point actually. If a doc wants to create a care plan for X, then X for patient P is by definition a 'problem' in that doc's opinion, and consequently in P's care. And that's where I think the care plan distinction breaks down. Good clinical practice would ideally mandate creating a plan for any issue brought up during a healthcare-patient encounter. Providers and patients may decide to ignore certain issues in a given setting but that doesn't help much either - the remaining issues would all become problems because they would all ask for a care plan. IOW, since all non-ignored issues want a care plan they all become problems. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
On Thu, Nov 20, 2014 at 12:57:38PM +0100, Karsten Hilbert wrote: Consider: the proof that something really is considered a 'problem', out of all the non-problems and trivial problems (e.g. one-off throat infection) is that some clinical professional wants to create a care plan, to define ongoing treatment and track interventions (all medications, other interventions etc). While I agree that that's something to consider I am creating care plans all day, for both complex and trivial problems. It is very much in the eye of the beholder what's trivial and what's not. My patients are so much the happier for their plan for one-off throat infection. well that's my point actually. If a doc wants to create a care plan for X, then X for patient P is by definition a 'problem' in that doc's opinion, and consequently in P's care. And that's where I think the care plan distinction breaks down. Good clinical practice would ideally mandate creating a plan for any issue brought up during a healthcare-patient encounter. Providers and patients may decide to ignore certain issues in a given setting but that doesn't help much either - the remaining issues would all become problems because they would all ask for a care plan. IOW, since all non-ignored issues want a care plan they all become problems. All in all we seem to mean the same thing except I contest the usefulness of requiring-a-care-plan to define problem. There can be problems which are of the nature take into account but don't directly act on for conducting other care. Say, a surgeon will be well aware of a patient's diabetes (as in considering causes for delayed healing, or considerate selection of drug therapies) -- and may want to record that as a patient problem -- but will not necessarily render associated care (until a toe needs to be taken off) and thusly will not establish a care plan. Perhaps the gist is: Issues for which a care plan is established are considered problems while there still may be problems without a care plan. Karsten Hilbert -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
On Wed, Nov 19, 2014 at 02:12:31PM -0300, pablo pazos wrote: The question was not how to do X in a POMR, the question was how to model a POMR in openEHR. Please read my first message to the list. I certainly did. I was not precise in my first wording. What I wanted to point out was that if we ask the question How to _view_ (display) an existing medical record _as_ a POMR ? we seem to have missed the fact (as to my understanding) that any existing medical record very much IS a POMR and that it cannot be any other way. Non-POMRs would seem to be data storage containers (of instances of medical data) rather than clinically useful _medical_ records. It is only the clinical integration of biological data (of whichever quality or type) that turns data into information and thusly a medical record. Is not for me to define what a problem is, I don't need/care to do that, that's for a physician to define. What I need is to provide an structure in which a physician can do that, using openEHR of course. What I've been wondering is that the need to turn data into problem-related information (in order to be useful) will seem so fundamental to any clinician that doing so would seem to be one of the first and foremost functionality of any medical record software. Also, POMR in this context is by Weed's definition, so it has a specific structure not every record has: a master problem list, statuses for each problem, progress notes for each problem, etc. (I wasn't aware that Weed had defined statuses on problems -- is there a link for reading up on that ? So for I only found http://www.geritech.org/2013/05/medicine-in-denial-problem-oriented-medical-record.html ) I agree that the Weed model of POMR seems best suited to comprehensive, longitudinal care but I would really like to learn of just one counter-example to the following proposition: Any medical record lends itself to being structured according to the POMR model. Therefore it should in order to afford internal clinical sense (what I am not saying here is that every clinician must be presented with a problem oriented view or even that that would best suit every clinicians workflow). In the other hand, yes, that information is in every MR, but you have to read a lot to find all the info relevant to a specific problem. What we need to do is to have that information linked in an explicit way to avoid that manual search, and have all the relevant info at one click of distance. IMO that was Weed's idea. Here we are on the same side of things. What I am stressing is that I would really expect any _information_ model intended for clinical use as a patient-centric medical record to easily afford the POMR approach. In my personal view it should really even enforce problem orientation internally. Otherwise said model would be a _data_ model (of which being an excellent one is really desirable). So, back to your question, are we looking for where exactly (and how) OpenEHR turns from a data model into an information model (as per my attempt at definition above) ? Karsten Hilbert Declaration of potential conflict of interest: I have helped implement a POMR. -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
Hi Thomas, firstly, I am not offering the Care Plan means of extensionally identifying problems as a bullet-proof method; it's just a working theory at this stage. Sure, I am not trying to put people wrong (I can't, at any rate), just treading the line a bit of being advocatus diabolus... For the above: wouldn't this patient normally have a diabetic care plan, and for surgery that is not diabetic related, then there will be a care plan for that, say 'left hip problem' or whatever. Agree. If the surgery is diabetic related, then it would presumably occur as an intervention that is part of the diabetic care plan? Agree except that the primary diabetic care plan would live at the GP office (or the diabetes clinic office) while the surgeon would now set up her own diabetes-related surgery care plan under the problem diabetes. However, even before that the surgeon would certainly want to record the fact diabetes as a problem such that she is reminded of one potential cause of future wound infections, delayed healing processes, ... in surgery *not* related to diabetes itself. A considerate surgeon would want to be able to recommend getting blood sugars checked and/or even switch from oral diabetes medication to insulin application for the time of healing of a non-diabetes wound. But there wouldn't be a diabetes care plan per se (at the surgeon's) during such times. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
How to do X in a Problem Oriented Record If one poses this question one has not understood one fundamental aspect of ALL medical records pertaining to a single patient (as opposed to epidemiological records): _All_ data is _always_ problem oriented. Any record keeping system must support attributing things to problems. Exactly what constitutes a problem depends on the patient, the provider, the level and type of care, the current focus of attention, the granularity of record keeping, circumstantical happenstance, knowledge of the day, etc. It may go so far as to seem to not be a problem oriented record -- in cases of extreme speciality, say, a geneticist only giving advice on one specific mutation in a given patient. That is, however, only a special case -- a singular problem -- of a problem oriented record. One can choose to ignore this fact but that is choosing to ignore a part of reality. Not necessarily inappropriate for solving a given problem but still fundamentally wrong (as to our current level of understanding of reality, of course). Documents are a special case since they often display properties of a summary of care over a range of problems and thusly need to be linked with several problems in a target record. Lab results are another case to consider: All things considered every single result (rather than the battery that was ordered) needs to be linked to potentially several problems. Batteries may get ordered on behalf of a single problem but results rarely apply to only one. Such is the wetware reality of healthcare involving actual human beings. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Problem-oriented records and querying by problem
On Wed, Nov 19, 2014 at 01:35:06PM +, Thomas Beale wrote: Consider: the proof that something really is considered a 'problem', out of all the non-problems and trivial problems (e.g. one-off throat infection) is that some clinical professional wants to create a care plan, to define ongoing treatment and track interventions (all medications, other interventions etc). While I agree that that's something to consider I am creating care plans all day, for both complex and trivial problems. It is very much in the eye of the beholder what's trivial and what's not. My patients are so much the happier for their plan for one-off throat infection. It's an interesting point of view. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Postulate: DV_QUANTITY should be modelled with fewest possible units
On Fri, Nov 14, 2014 at 01:55:56PM +, Ian McNicoll wrote: I am sure that could be done but it would mean replicating these kind of statements in every archetype that had multiple units. This really feels like something that should be handled computationally at RM level- it is universal and a property of the units not of the archetype. Uhm, yeah, well, no. There are units in use which only apply in context -- their conversion would require knowing, say, the substance measured. And that's only those that actually _make_ any computational sense. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Postulate: DV_QUANTITY should be modelled with fewest possible units
On Sun, Nov 16, 2014 at 12:02:00PM +0100, Karsten Hilbert wrote: There are units in use which only apply in context -- their conversion would require knowing, say, the substance measured. think mg/dl - mmol/l Karsten Hilbert -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
SV: ACTIVITY and timing
On Wed, Aug 14, 2013 at 08:11:50AM +0100, Thomas Beale wrote: There is no assumption in ACTIVITY.time that the activity is repeated. In the GTS syntax, you can just as easily express a one-off event at a certain time as you can a repeated event. If you use cron syntax, I think you just put a full date / time from memory (although that's pretty unusual usage of cron syntax). One crucial thing is to ensure that these data remain interoperable. To do that, we need to limit the syntaxes that could be used in ACTIVITY.timing to a reasonably small number, and standardise their use. I am not sure for example, if it will be a good idea to have 3 ways of expressing '3 times/day for 7 days' or other typical things. Adding a namespace (prepending cron://, GTS:// or some such) may help. Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
SV: ACTIVITY and timing
On Wed, Aug 14, 2013 at 11:41:58AM +0100, Thomas Beale wrote: the problem isn't to do with not knowing which formalism is being used - the DV_PARSABLE type takes care of recording that. I am just saying that having too many alternative ways for implementers to support is not necessarily a good thing True enough. Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Trying to understand the openEHR Information Model
On Mon, Apr 15, 2013 at 08:40:59PM +0200, Bert Verhees wrote: On 04/15/2013 06:12 PM, Thomas Beale wrote: patient sees the GP, then visits a practice nurse, without the GP record being committed first. yes, that's certainly a possibility, if the practice solution isn't designed to deal with it, and the staff are not trained... In the Netherlands there is, what we call, the door-handle-patient. At the moment he is leaving the room, and is busy opening the door, he tells what he is really worried about. That's standard GP land. The GP asks the patient to sit down for an extra minute and explains why he thinks it is not cancer, or he makes another appointment because he thinks the patient has a point.. So a GP at latest should commit after the door is closed and the patient has definitely gone and just before the new patient enters. For one thing that moment (the patient being gone for good) never comes in reality. However, there's no need to define such a moment in time. The GP writes into the EMR whatever is known at any point during the consultation. Yes, that will be subject to editing, deleting, amending, but that's normal ! The nurse (that is, any other workplace of the GPs network) will see whatever has been committed. Whenever something is committed a change notification is pushed out by the storage engine and clients can update themselves if relevant (that's how GNUmed does it). This, of course, does not yet solve the conflict of the user editing something that's just being changed but at least there's no chance to not be aware of it. At the moment a patient arrives again at the nurses or assistants-desk, the dossier should be fully up to date, or it should be recognizable that it is not up to date In reality fully up to date never happens. It is always the current state of affairs. and then the nurse has to wait until the lock is released. Ah, no, it doesn't make a difference whether the nurse waits for a lock to be released or not - because even if the GP released the lock the nurse has no way of knowing whether the GP committed everything (instructions) needing committing or whether the GP forgot something. That can only be assured by out-of-band means, say, the patient knowing what the nurse needs to do for him (or GP and patient agreeing and sending an action sheet *before* the patient leaves the room -- and still that does not prove the GP does not remember something needing doing after the patient left the exam room). It is a problem not solvable by technical means alone. Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
openEHR members, who we are?
This is a good idea.Unfortunately we only store members names and email addresses as part of the list. In many cases the email address is unhelpful in determining the location of the member. There are currently 428 members on the clinical list. So far we have resisted the idea of a more formal membership list with other member details but perhaps this is something that should be reconsidered. Certainly don't make it mandatory. Karsten
Articles on Healthcare, Complexity, Change, Process, IT and the role of openEHR etc
On Sat, Oct 23, 2010 at 05:26:48AM +0100, Derek Meyer wrote: I don't claim that all old information is useless. My hypothesis is that clinical care generates vast amounts of information, and very little of this vast amount is useful.? Make that ... at any one time. a) converts real patient records into facts, and the counts the number of facts, b) requires patients to be seen without a written health record and a treatment plan formulated, c) reviews the treatment plans in the light of the written record, and d) counts facts which result in changes to the treatment plan, e) calculates the ratio of facts that were useful in altering the treatment plan compared with the total number of facts.) Once it was said If human beings were alike medicine could become a natural science. That is why the above plan is doomed to fail. This is an economic problem, Health is NOT an economic problem. Care can be, but health is not. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Articles on Healthcare, Complexity, Change, Process, IT and the role of openEHR etc
On Sun, Oct 24, 2010 at 11:58:31AM +0100, Thomas Beale wrote: I think that the 'pebbles nuggets' characterisation is probably right, although I don't think anyone knows what the balance is, It isn't even easy to (sometimes not even possible) to know what are the pebbles and what are the nuggets. In fact, pebbles may turn into nuggets. I think that what will be needed in the future is a way of filtering out the useless pebbles on the way so to speak. Perhaps when data were archived onto slower media. I wonder if anyone has seen research to indicate how far back data might be useful based on specific morbidities? That probably wouldn't be useful because we don't yet know which morbidities are going to be relevant for a given not-yet-patient. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
MedInfo 2010
On Tue, Dec 01, 2009 at 10:42:52PM +0900, KOBAYASHI, Shinji wrote: 0) Adjust all workstation using NTP server There seems to be no reason for this, if we don't have to keep our workstations in synch. 1) Tim send me the file recorded 'event1', '2009-10-30T12:18:11BST' 2) I received file and record it after change BST to UTC 'event1, '2009-10-30T09:18Z' and record with timestamp. 3) I send Tim with the file recorded 'event2', '2010-01-22T01:22:22JST' So you change the datetime on your workstation independently of the other workstations, right? I cannot understand what you meant in 'independently'. For some authentication procedure, we need to sync date tome on our workstation. So wee need 0). Exactly. What was proposed was to not use an *official*, true-time, NTP time server but rather declare one local machine as *being* the *local* NTP time server for all other machines taking part in this connectathon. That way, time can be spun forward on just that one local time server and all other workstations can be expected to re-sync into the future via NTP within their re-sync timeout. Makes things a lot easier. I think the time in record, when the event happened, does not depend on the clock of the workstation. Sure, that's another approach. But using the local NTP approach one can *simulate* progress of real time, not just assume it. HTH, Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
CQuantityItem.units not empty
On Tue, Feb 10, 2009 at 02:01:59PM -0500, Greg Harris wrote: Not that it's dispositive of any larger issue, but doesn't VAS actually record a physical quantity (specifically, the centimeter position on the horizontal line where the patient indicates the level of pain)? 7 centimeters of pain ? No, that's just a device, a metaphor, basically. It does add a bit of comparability, though. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
On Fri, Jun 27, 2008 at 07:54:36AM -0300, Tim Cook wrote: They should probably be designing another By Physicians for Physicians EMR. Do we really need another one of those? No we don't and some of them are only still existing until sufficiently advanced OpenEHR based implementations exist (and, no, PatientOS doesn't count towards that because its focus quite apparently is inpatient care). Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
openEHR Querying specifications
On Tue, Jun 03, 2008 at 11:26:08PM +0200, Mikael Nystr?m wrote: I therefore think that excluding the version information can result in a mess. It shouldn't, of course, be excluded by default but should be excludable on demand. By, say, allowing regex matching for path definitions. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
openEHR Querying specifications
On Wed, Jun 04, 2008 at 12:42:56AM +0200, Mikael Nystr?m wrote: It shouldn't, of course, be excluded by default but should be excludable on demand. By, say, allowing regex matching for path definitions. To be excludable on demand is probably a good solution, but I still think that there is a benefit if it is possible to see which version of the archetype the query was written for. If it's excluded on demand in a particular query then the query is written to work on any version - quite by design. Of course, the version can be included in the SELECT list so that one may learn which version actually matched the query. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
openEHR Querying specifications
On Wed, Jun 04, 2008 at 09:09:56AM +0930, Heath Frankel wrote: Versions should be handled using the regular expression syntax of the archetype ID, as is done in ADL to represent slot constraints and action_arcehtype_id in ACTIVITY. E.g. [openEHR-EHR-COMPOSITION.encounter.v1*] [openEHR-EHR-COMPOSITION.encounter.v\d+], hopefully ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Decision Support was: MIE-2008
On Mon, Jun 02, 2008 at 09:48:17AM -0300, Tim Cook wrote: I'd really like to see the outcomes of a little project which would be about porting a simple existing decision support system to an OpenEHR based infrastructure. Warning against adverse drug events for patient safety would be a good target for example. (mostly) rewriting this kind of app would give valuable feedback to archetype designers and also standard developers. Doing adverse drug reactions isn't too tough of a technical problem. It is however a MASSIVE knowledge problem. Using clinical guidelines to determine things like immunization adherence etc is a much butter place to start IMHO. Full ACK. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Decision Support was: MIE-2008
On Mon, Jun 02, 2008 at 09:45:08AM -0300, Tim Cook wrote: The EVIDENCE-BASED GUIDELINES AND DECISION SUPPORT SYSTEM (EGADSS) The basic concept is that an EMR sends a basic known set of information about a patient to the DSS. The DSS processes whatever clinical guidelines it knows about using the CLIPS Inference Engine http://clipsrules.sourceforge.net/ and if it finds something applicable to this patient it processes the guideline. If it needs more information (lab results etc.) it sends a request back to the EMR. The guideline analysis is completed and instructions returned to the EMR. That's precisely how I would want a DSS to work for interfacing it with GNUmed. When I last looked at EGADSS (a year or so ago) it looked like they wanted me to use their own GUI not just for defining guidelines but also make the user use their GUI to check for guideline adherence of patients handed over from an EMR. IOW, I couldn't find any documentation on how to get instructions back into GNUmed. Any pointers ? A re-implementation of this engine using GLIF instead of Arden Syntax guideline encoding and using an openEHR EHR Extract instead of the CDA for messaging is certainly in my future plans. Looking forward to that. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
persistence
On Thu, Jan 03, 2008 at 11:26:23PM +0100, Bert Verhees wrote: But what we, as community, can do is building an API to which the kernel can connect, every or most possible persistence solutions should be able to fit below. That is where I would like to help, that is the missing part in OpenEhr which we can do together, so why don't we? Why do discussions die, when they enter this subject? I would like to know that. IMO the answer is easy. Eventually, a good API crystallizes from several (attempted/undertaken) *implementations* of a specification. Implementation means work. Nitty-gritty, non-theoretical work. Day-job bores. There's two kinds of (useful) people (and pray, both are needed) in IT: Those that figure out *how* to do something right (Thomas Beale and his clan). And those that *do* it (Bert and friends). The former, by design, need more visible communication, it seems to me. The latter just need to get down and DO it. The (volunteer/OSS) doers are a minority in my observation. If one wants an implementation to happen one needs to start one (and preferably open source it). From there one can go back and define a sensible API between specs and implementation which will not fall down with the next implementation. My 2 Cents, Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
persistence
True, API persistence layer should be generic as said previously mentioned. Although originally it needs to be developed based on a reference DBMS and for this DB2 looks attractive (quick results?) on first sight. Not any more than, say, PostgreSQL. Actually less so, some are likely to argue. I, for one, wouldn't bother trying to get DB2 to work on my Debian systems were I to test-drive an OpenEHR persistence engine. Other equally capable and more conveniently licensed DB engines come bundled with many a self-respecting operating system. Karsten -- Pt! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=10
Transforms
On Tue, Dec 11, 2007 at 11:33:05AM +0100, Erik Sundvall wrote: I agree regarding the value of being technology neutral. The model has been described in UML and implemented in Eiffel (.NET) and Java and as I understand Ruby and Python are underway I'd be highly interested in the whereabouts of the Python part. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
ECG archetypes
On Fri, Mar 09, 2007 at 10:22:12AM -, Ian McNicoll wrote: This did make me wonder if it is always appropriate to create a detailed archetype for this kind of biomedical data, or should it perhaps simply be stored/referenced as a blob or link. In GNUmed we draw the distinction like this: If the detailed data can be made sense of by another application with much ado it make sense (in principle) to create a detailed archetype. If it only really makes sense to the originating application (the ECG software of the company in this case) it doesn't make much sense to go beyond storing it as a blob and handing it out to the original application on demand. Now, of course, *any* data can be made sense of given appropriate specs. Also, that's the whole purpose of archetypes - to make data self-descriptive and self-consistent. And in an ideal world one would want to map the original data into a perfect ECG archetype and map it back into whatever interpreter of such information is the target. But one also sometimes needs to walk the path of pragmatism. OTOH it may be useful to have a detailed ECG archetype to encourage direct use of it in *future* applications. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN published En13606-1 EHRcom. Tutorial about Archetypes
On Wed, Mar 07, 2007 at 12:43:51AM +0100, Gerard Freriks wrote: ... ... revolutions, that changed society ... Past Tense ... And EN13606 and openEHR will be the same. Future Tense Revolutionary can only be applied after the fact. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN published En13606-1 EHRcom. Tutorial about Archetypes
Anything dubbed revolutionary raises cautionary red flags. As Adrian Midgley once aptly put it: Ars longa, IT brevis. Karsten On Tue, Mar 06, 2007 at 12:10:09PM +0100, Gerard Freriks wrote: Subject: CEN published En13606-1 EHRcom. Tutorial about Archetypes X-Mailer: Apple Mail (2.752.2) Dear reader, Healthcare of the future needs ICT-systems of the future. Healthcare needs systems that are: -patient safe, -help respect privacy and -make 'plug-and-play' exchange between systems possible, CEN/tc251 has published part 1 of a new exciting European standard for the EHR. It is CEN/tc251 EN13606 EHRcom. Together with other CEN standards it will make possible 'plug-and- play' semantic interoperability between conforming EHR-systems. 1- ConSys: System of Concepts for Continuity of Care describes the concepts clinicians need to co-operate 2- EHRcom: EHR standard that helps store, retrieve, present, and exchange data, information and knowledge 'plug-and-play' without reprogramming 3- HISA: Health Information Services Architecture that makes co- operation between systems possible. The revolutionary 'plug-and-play' is possible because of a new paradigm: the Archetype Paradigm. Complex and resource intensive processes like IHE will not be necessary to implement many message specifications. It must be clear that deployment of these standards can play an important role to achieve the i2010 goals accepted by all Member States. And is exactly what healthcare of the future needs In the attachment a draft presentation with more information about the CEN standards. March 29 and 30 a tutorial about the new revolutionary European EHR standard and Archetypes will be held in Leiden. More information can be found at: http://web.mac.com/g.freriks/iWeb/conexis - Welcome tutorial at conexis.nl With regards, Gerard Freriks former chairman of CEN/tc251 wg1 conexis --- Gerard Freriks, MD Huigsloterdijk 378 2158LR Buitenkaag the Netherlands M: +31 620347088 gf at conexis.nl ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Normal and other ranges
On Wed, Sep 20, 2006 at 11:08:10AM +1000, Vincent McCauley wrote: What action should flow from even critical results depends on the clinical context. A total CPK (marker of muscle damage) flagged as critically elevated will require different responses in a patient who has just had an intramuscular injection from that in a patient with chest pain. GNUmed uses two flags to account for that: technically_abnormal clinically_relevant Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Lifestyle: substance_use archetype
On Wed, May 10, 2006 at 06:38:07AM -0500, Bill Walton wrote: Could you say more about the need for 'substance use' archetypes? I'm not sure I understand why it would be a good idea to record alcohol consumption differently from, for example, consumption of herbal teas. Or prescription drugs for that matter. I'm sure I'm missing something. Recording substance use is more intended to record a *fact* about the lifestyle of an individual rather than an *intent to treat* as with prescription drugs. There's a fine line as always: herbal teas, OTC drugs etc may or may not have been intended to be treatment by the provider. However, disambiguating such in a given case is at the discreetion of the provider/patient in question. OpenEHR needs to provide facilities for both. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Lifestyle: substance_use archetype
On Wed, May 10, 2006 at 05:08:09PM +0200, Gerard Freriks wrote: The EHR is about recording observed facts. One of those facts is the use of substances. Irrespective of a regular drug, herbal tea, food additive, smog, self medicated, prescribed, or taken by an involuntary action one always want to record the same things. So why not a generic Archetypes: Observation: Substance Use Concise, as always. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Pathology numeric values not supported in DV_Quantity
On Tue, Apr 25, 2006 at 10:03:12AM +0100, Thomas Beale wrote: Not sure of the need for = or =. It's either beyond the value reading capability of the device or an actual value is record (within some accuracy tolerance). yes, this has already been mentioned - Vince has never seen it in the millions of results his software has processed. Vince suggested we put it in for completeness, but now that you hvae made me think of it...maybe we should only allow what makes sense, i.e. =, , .with ~ still to be resolved... = = do happen over here in Germany. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
notarization, was: Re: removal of data
On Mon, Apr 24, 2006 at 07:10:08PM +1000, Tim Churches wrote: OK, that sounds good. An alternative modus operandi for digital notarisation is for the EHR to generate a self-signed digest for each new version of a record, send that digest to a third-party notary, who then counter-signs the digest and sends it back to the EHR, which then stores the counter-signed disgest in the repository alongside the record to which it applies. That means that the digital notary does not need to store anything other than their complete history of private signing key(s), and anyone can check the validity of the notary's counter-signature by referencing the public signing key for that notary for the date on which the record was counter-signed. The notary does not have to be consulted or bothered for that validity check to occur. If the counter-signature is valid, then the stored digest is valid, and if a new digest calculated from that version of the record matches teh stored digest, then it provides strong evidence that that version of the record existed in that state at some time prior to the counter-signing date. Because notaries don't need to remember anything other than their signing keys, they can be very cheap to set up and operate, and can be made very secure eg run a hardened Web server with minimal facilities and no writable storage. But there needs to be somewhere in the openEHR record to store the counter-signed digest. Or maybe more than one - it is possible that several separate notaries could be used to provide triangulation of their attestation functions. http://www.gnotary.de provides just that. The site is in German. It offers an implementation of what Horst Herb originally proposed in the gnotary concept. The academic idea transformed into an open source project (GNotary) transformed into a product (gnotary.de website and business). Contact Sebastian for information in English (my brother, so add standard disclaimer here - oh, and I wrote most of the original code for the gnotary server, so there). Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
notarization, was: Re: removal of data
On Mon, Apr 24, 2006 at 08:43:35PM +1000, Tim Churches wrote: http://www.gnotary.de provides just that. The site is in German. It offers an implementation of what Horst Herb originally proposed in the gnotary concept. ... Contact Sebastian for information in English (my brother, so add standard disclaimer here - oh, and I wrote most of the original code for the gnotary server, so there). There is an English version of some documentation for Gnotary by Horst Herb at http://www.gnumed.net/gnotary/ However I don't think the gnotary server described on that page is currently functioning. Right, it is not. But the gnotary people from the URL given above run one which can be tested freely and under certain circumstances be *used* freely (by FOSS projects, roughly). The source is FOSS, too, of course. The API is SMTP. Sebastian has the inside scoop. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
removal of data
On Fri, Apr 21, 2006 at 10:11:47PM +0100, Thomas Beale wrote: entered by a physician or nurse wrongly using patient A's EHR). There might be other ways it could get there, but in openEHR, if the info was put in record A, there is no way to know it was meant for somewhere else. Well, a common scenario would be a scan of a discharge letter being attached to the wrong patient. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
persistence layer
On Fri, Mar 17, 2006 at 05:45:27PM +0100, Mikael Nystr?m wrote: If we are talking about small data driven systems can I accept the ?pure Java guy?s alternative? and do most of the processing in Java. But if we would like to have large data driven systems this alternative is needs in most cases to large resources to work, and we then need to use the ?database engineer?s alternatives? instead. Well, even in a GP EMR system we want decision support. I don't think there's any such thing as a small system in your sense. It's rather a question of what the system is going to be used for no matter large or small. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
FW: persistence layer
On Thu, Mar 16, 2006 at 12:57:08PM +0100, Mikael Nystr?m wrote: I think before we discuss how we are going to build a persistence layer we need to discuss how we are going to use it. Is it to support a simple electronic healthcare record application which only collects basic information, print the information on a computer screen or on a paper on a small center for primary health care? I want to use it for that. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Pathology numeric values not supported in DV_Quantity
On Wed, Mar 01, 2006 at 08:31:23PM +0930, Sam Heard wrote: I like the flags - I wonder if we should have a ? or ! for the value affected by a quality issue - what do others think? Probably ? for dubitable results. ! is commonly used here for marking up (perhaps unexpectedly) clinically important results (such as an *unusually* high titer of something where I expected either normal or somewhat elevated). Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Suggestion about the Multi-axial Archetype Indentifier
On Thu, Feb 16, 2006 at 11:47:40PM +0100, Rong Chen wrote: But, do we really want to work with different version of RM at same runtime system? That isn't really a useful question. The situation of having different versions to deal with will be presented to us at some point by Murphy's Law. And even if we decided we don't want to *deal* with that then it'd be helpful to be able to simply ask the archetype what version of the RM it came from such that to decide whether we want to deal with this archetype instance. An archetype without proper and full version information feels like a table without a primary key. It'll work but it may turn ugly any minute. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
[GPCG_TALK] Archetype Maintenance
On Mon, Jan 09, 2006 at 07:49:02AM +1100, Tim Churches wrote: Certainly most of us would like that to be true. I was just wondering aloud whether it was true in a strict legal sense. I suspect that it is an issue which requires expert legal advice, and the situation may be subtely different in each country due to differences in copyright law. It just seems like a good idea to investigate such issues when adopting a new paradigm for storing and communicating data. Most definitely, Tim. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
The Uncertainty Decision was: Dr R LONJON Confidence indicator !
On Sat, May 07, 2005 at 02:12:45PM +0100, Thomas Beale wrote: If angina pectoris is a possible diagnosis for burning chest pain at 5%, with the most probable diagnosis (in the opinion of the physician) being gastric reflux at 95%, and it is a 55-yo with a family history of coronary heart disease, I presume that the angina pectoris possibility is the one that drives the next steps? How are the confidences really decided? If it's a 55-yo with a family history of coronary heart disease and the doctor thinks angina pectoris is at 5% while gastric reflux is at 95% then it is either a failure of the doctor to get his probabilites straight - or else the doctor is truly clueful (eg knows the patient very well) - in which case, yes, the gastric reflux would be driving the next steps. How are we to bridge the gap between the physician-recorded confidence factor and the total list of factors which drive the next steps? In such cases I usually record IMO this but that not r/o yet hence act on this but also do foo to differentiate. In clear text. 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
EntityNameParts
On Fri, Mar 11, 2005 at 10:31:09AM +0100, Bert Verhees wrote: Op donderdag 10 maart 2005 13:48, schreef Karsten Hilbert: There are no fixed patterns for names or naming conventions. There are many societies where there are no 'Family' names at all. Some have Tribe names in lieu, some with father's or village name as 'names' somewhere wedged in the name string. Some with just unique names with nothing else. To add to this confusion you would then have to find sub-components for nick names and aliases. Yes, the whole gamut :-) In GnuMed we deal with it like this: Where do you put initials and how do you qualify them as such so they can be recognized in an automated process. We don't have dedicated initials support. Most of the time (I know no other use) initials are the first character of the first name(s). So we either store them as first names (if we don't know the first name but know the initial) or we do not store them. I do not completely understand why you need to be able to *process* initials ? 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
Can you precisely say what your initials stand for ? Here in Germany they are *always* the first letter of the first name(s). In other countries, too (US, AU AFAICT). In a name, that is. A sig may consist of initials only - first/last names both included - such as on charts etc. In that system, initals stands for the first characters of the christiannames, but that said, it depends on what the GP has used the field for. But that was what the interface asked him/her to do That then means you can do this: - check if there are first names - if yes - check if the initials match - if yes - forget the initials: you can recreate them - if no - store them but don't worry about what they mean because you cannot know what they mean (eg the source system does not provide that information) *see below - if no - assume the initials *are* the first name initials - store them in the firstnames field directly *) Now, of course, one doctor will come up and say But I always used that field to store the stardate equivalent of that patient's grandmother's marriage ! In that case (if you want to keep that information for that doctor) you should postprocess the data exported from his source system and store the data in a new field patient_grandma_marriage_as_stardate in your system. Only half kidding. 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
EntityNameParts
On Sat, Mar 12, 2005 at 09:28:37AM +, Thomas Beale wrote: I do not completely understand why you need to be able to *process* initials ? You definitely do. If your name is F. Murray Abraham (to use the name of the actor who played Salieri in Amadeus) and that's what you present yourself as, then the EHR system had better not mess it up. It probably should record what the F. stands for, but still needs to remember that it is always used in the initial form with both the patient, the health service and payers. I understand that. Let me rephrase my question: I do not completely understand why you need to be able to *process* first name initials any different from fully spelt out first names ? 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
EntityNameParts
On Fri, Mar 11, 2005 at 10:31:09AM +0100, Bert Verhees wrote: Op donderdag 10 maart 2005 13:48, schreef Karsten Hilbert: There are no fixed patterns for names or naming conventions. There are many societies where there are no 'Family' names at all. Some have Tribe names in lieu, some with father's or village name as 'names' somewhere wedged in the name string. Some with just unique names with nothing else. To add to this confusion you would then have to find sub-components for nick names and aliases. Yes, the whole gamut :-) In GnuMed we deal with it like this: Where do you put initials and how do you qualify them as such so they can be recognized in an automated process. We don't have dedicated initials support. Most of the time (I know no other use) initials are the first character of the first name(s). So we either store them as first names (if we don't know the first name but know the initial) or we do not store them. I do not completely understand why you need to be able to *process* initials ? 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
EntityNameParts
Can you precisely say what your initials stand for ? Here in Germany they are *always* the first letter of the first name(s). In other countries, too (US, AU AFAICT). In a name, that is. A sig may consist of initials only - first/last names both included - such as on charts etc. In that system, initals stands for the first characters of the christiannames, but that said, it depends on what the GP has used the field for. But that was what the interface asked him/her to do That then means you can do this: - check if there are first names - if yes - check if the initials match - if yes - forget the initials: you can recreate them - if no - store them but don't worry about what they mean because you cannot know what they mean (eg the source system does not provide that information) *see below - if no - assume the initials *are* the first name initials - store them in the firstnames field directly *) Now, of course, one doctor will come up and say But I always used that field to store the stardate equivalent of that patient's grandmother's marriage ! In that case (if you want to keep that information for that doctor) you should postprocess the data exported from his source system and store the data in a new field patient_grandma_marriage_as_stardate in your system. Only half kidding. 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
