Re: Archetype modelling pattern for Physical examination findings
Dear colleagues, I looked at the page url provided and have difficulty to inspect the figures because of a low resolution. I agree that a more patterned way is necessary in order to have EHR systems that have access to more uniformly defined data needed for processing. This requirement I call: Interpretability. When all kinds of Observations need to be expressed in a uniform way we need ideally: 1- We need uniform patterns for each possible observation and all the various ways in which observations are expressed 2- We need to cater for ways to express the metadata of Observations that are part of a meaningful list 3- We need to cater for ways to express the metadata of the observation, itself 4- We need to cater for ways to express the metadata around the data subject 5- We need to cater for ways to express the metadata of the treatment process of the topic 6- We need to cater for ways to express the metadata of the clinical process 7- We need to cater for ways to express the metadata of the documentation process 8- We need to cater for ways to express the metadata of all the contextual information ad1: e.g. quantitative-, semi-quantitative-, qualitative observations expressed using: numbers, text, codes, and many units of measurement, ad2: e.g. Blood pressure, Lab panels, … ad3: e.g. seeing, hearing, touching, smelling, tasting, … ad4: e.g. body position, before, during or after exercise, etc. ad5: e.g. reason for encounter, data collection/observation, history, examination, evaluation, planning, ordering, execution ad6: e.g. intake, investigation, treatment, referral, ad7: e.g. de novo recording of a fact, re-use of previously, recorded facts, clinical data, administrative data, preliminary data/unprocessed data, data admitted to the record ad8: e.g. localisations in time and space in absolute and relative terms In my way of thinking I start with the documentation process in the ENTRY with two CLUSTERS. One for the context data and one for the Panel. The Panel consists of a CLUSTER for each Panel component and one for the context of all. And then per Panel component two CLUSTERS: one for data and one for its context. Gerard Freriks +31 620 34 70 88 +31 182 22 59 46 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 7 Mar 2019, at 05:33, Heather Leslie > wrote: > > Hi everyone, > > The CKM editors have been gradually refining our views on how to model > Physical examination findings for many years now. There have been many hours > wasted exploring options that have had dead ends. We’d like to prevent others > having the same experience by sharing and publishing an agreed pattern and we > feel that we have one ready for broader consumption. > > We clearly needed to find a solution that works from a modelling point of > view ensuring that the clinically diverse requirements are catered for, as > well as the needs of implementers for querying etc. > > I have developed a page on the wiki to try to explain our proposal and > provide some examples - > https://openehr.atlassian.net/wiki/spaces/healthmod/pages/380993560/Proposal+-+Physical+examination+findings+pattern > > <https://openehr.atlassian.net/wiki/spaces/healthmod/pages/380993560/Proposal+-+Physical+examination+findings+pattern> > > Comments welcome, probably best if you add them to the wiki page, please. > > Regards > > Heather > > Dr Heather Leslie > MB BS, FRACGP, FACHI, GAICD > M +61 418 966 670 > Skype: heatherleslie > Twitter: @atomicainfo, @clinicalmodels & @omowizard > www.atomicainformatics.com > > > ___ > openEHR-clinical mailing list > openehr-clini...@lists.openehr.org <mailto:openehr-clini...@lists.openehr.org> > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > <http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org> ___ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
Re: Is partial datetime pattern (yyyy-mm-ddTHH:??:??) equivalent to "any allowed"?
My ideas about this topic. Two distinct different times we need to consider: -Time (physical) at the system level to be used for Timestamps, including Time zone Chronos is the greek deity associated with it. A specific generic data type will deal with this. - Time as used by humans. Including Time zone but also things like week, autumn, midnight, and associated time relationships like before, after, during, overlapping, etc. The associated Greek deity is Chairos. The Chronos Time is modelled using a data type. The Chairos Time is modelled via Archetypes using the Data Types but augmented with attributes taken from the proper ontologies. Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 19 Mar 2018, at 01:56, Pablo Pazos <pablo.pa...@cabolabs.com> wrote: > > Hi, > > I'm digging into the specs again, and testing the modeling tools to produce > different constraints for DV_DATE_TIME. > > When I analyzed the partial datetime pattern -mm-ddTHH:??:?? that allows > optional minutes and seconds, and the constraints that would correspond to > "any allowed" it seems both are the same. I'll explain. > > "any allowed" for DV_DATE_TIME would be any value that actually is a > datetime. For instance "1999-01-01" is not a datetime, so "any allowed should > check for datetime that at least has hours, that is something like > "1999-01-01T16". > > Having "1999-01-01" as a datetime would be a type mismatch if we are strict. > With relaxed rules we can say "1999-01-01" is equivalent to > "1999-01-01T00:00:00", but we are assuming something that might not be the > intent of the user that inputs the data. Since this is health date, I prefer > the strict approach. > > But if we have the partial datetime pattern, that is validating the same, > that at least the hours are there, then minutes and seconds are optional. > > Invalid datetime like "546454" won't be valid on any allowed or partial > pattern > Date only like "1999-01-01" won't be valid on any allowed or partial pattern, > since it is not a datetime, is date > Date with hours, will be valid on both > Date with hours and minutes, will be valid on both > Date with hours, minutes and seconds will be valid on both > (on all cases timezone information can be added, if it is not present, UTC is > default) > > > Considering this, it seems both are equivalent. So why allow both? > > IMO this generates a point where implementers can have different > interpretations and implement both constraints in a different way (any > allowed and partial pattern). > > > What do others think? > > > Thanks! > > -- > Ing. Pablo Pazos Gutiérrez > pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com> > +598 99 043 145 > skype: cabolabs > <http://cabolabs.com/> > http://www.cabolabs.com <http://www.cabolabs.com/> > https://cloudehrserver.com <https://cloudehrserver.com/> > Subscribe to our newsletter <http://eepurl.com/b_w_tj> > ___ > openEHR-implementers mailing list > openEHR-implementers@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org ___ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
Re: Mandatory elements in archetypes, and user interfaces
Hi, You are right; I agree with you. But … Archetypes (most times) have to be very forgiving with constraints. Archetypes are used to build Templates. These are created for a specific purpose in a specific circumstance. Templates are used to specify interfaces and then most constraints have to be set fully. Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 10 Nov 2017, at 15:49, Boštjan Lah <bostjan@marand.si> wrote: > > > >> On 10 Nov 2017, at 15:03, GF <gf...@luna.nl <mailto:gf...@luna.nl>> wrote: >> >> Why isn’t it a good idea? > > Perhaps it's just a matter of taste, but it makes no sense to me to have > something stored into container Diagnosis and then not have an actual > diagnosis code in it. > Same for temperature, blood pressure, etc. > Perhaps I can make a counter-question - can you give an example where this > makes sense? > > Bostjan > > ___ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
Re: Mandatory elements in archetypes, and user interfaces
Why isn’t it a good idea? Give an example, svp. Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 10 Nov 2017, at 14:21, Boštjan Lah <bostjan@marand.si> wrote: > > > >> On 10 Nov 2017, at 14:19, Thomas Beale <thomas.be...@openehr.org> wrote: >> >> >> >> On 10/11/2017 10:24, GF wrote: >>> Hi, >>> >>> Even when elements make no sense when both are recorded, even then 1..1 is >>> a problem in Archetypes. >>> It is up to the implementer to decide to restrict 0..n further in the >>> Template. >> >> you can't restrict from 1..1 => 0..* in a template - it's not allowed in any >> restriction algebra, of which ADL is an example. >> >> If it is thought that no occurrnces constraint might be needed in any >> derivative archetype or template, the original parent should have 0..1 or >> 0..* as appropriate. > Yes, but I think making all archetypes generic like Gerard suggests is not a > good idea. > > Bostjan ___ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
Re: Mandatory elements in archetypes, and user interfaces
Hi, Even when elements make no sense when both are recorded, even then 1..1 is a problem in Archetypes. It is up to the implementer to decide to restrict 0..n further in the Template. I suggest to make archetype as generic as possible and use almost always 0..n Implementers are exposed to Templates but NOT Archetypes. Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 10 Nov 2017, at 11:47, Bakke, Silje Ljosland > <silje.ljosland.ba...@nasjonalikt.no> wrote: > > Crossposting this between the clinical and implementers lists, since it > belongs in both: > > In some archetypes, one or more elements are set as mandatory (typically > occurrences 1..1 or 1..*), because the rest of the concept makes no sense > without this particular element recorded. Examples are Problem/diagnosis name > in Problem/diagnosis, and Temperature in Body temperature. This is not > intended to mean that it’s mandatory to enter data into the element in a UI, > but that this particular element is mandatory in any persisted composition > that uses the archetype. > > Recently however, we received a request to change the Head circumference > element in the Head circumference archetype from 1..1 to 0..1 because the > element being mandatory in the archetype automatically made the UI form > builder mandate the entering of data into the UI field, and removing the > archetype on the fly made more unnecessary clicks. In a fit of mental > hiccups, I agreed with and performed this change, but have since realised > this is wrong, because: > · A mandatory archetype element is not the same as a mandatory UI field > · A mandatory UI field is more like a field where you only allow > persisting non null values, while a mandatory archetype element can be > persisted with a nullvalue without a problem. > > How are implementers actually handling this? Do you separate UI field > mandation and archetype element mandation? > > Kind regards, > Silje Ljosland Bakke > > Information Architect, RN > Coordinator, National Editorial Board for Archetypes > Nasjonal IKT HF, Norway > > Tel. +47 40203298 > Web: http://arketyper.no <http://arketyper.no/> / Twitter: @arketyper_no > <https://twitter.com/arketyper_no> > > ___ > openEHR-implementers mailing list > openEHR-implementers@lists.openehr.org > <mailto:openEHR-implementers@lists.openehr.org> > http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org > > <http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org> ___ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
Re: Versioning implementations
I notice the versioning discussion. Is see three different topics; (non-)Persistent, versioning and synchronisation/consolidation. I see no use of non-persistant flags. I see two reasons for versioning. Synchronisation,consolidation is too complex for now. ERS systems document events. Each documented event is equally important to document. What is important now is not later. And vice versa. Always a subjective opinion is documented by the author. Persistent Depending on circumstances an event is important or not. In this context I fail to grasp the need to label certain events as persistent and others not. All documented events need to persist in EHR-systems. Lists re-used data. Some events warrant to be re-used in context dependent lists: Active medication, Problem list, Previous diagnosis, etc. Each context, HcProvider will need different lists for different purposes. These lists are the result of documented events and persist. Creating lists is an example of re-using data, because list content is derived from pre-existing events/data. These lists are either changing are not-changing over time. Versioning Lists Lists can be updated as the result of new events in the patient system and therefor need to be versioned. These are non-technical new versions. They are the result because of changes in the patient system Versioning events While documenting events and committing them to the data base sometimes event data needs to be changed, updated, corrected. The same event gets a new technical version, because nothing in the patient system changed but the documentingHcProvider initiated the change. Synchronisation, merging, syncing This is a complex topic. Is there an extensive list of examples and requirements? Gerard Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 18 Aug 2017, at 13:49, Pablo Pazos <pablo.pa...@cabolabs.com> wrote: > > From Thomas comments, it is clear that we have such last two use cases, > internal versioning and cross-system versioning / sync / consolidation. > > Consider people here is talking about their own experience with the specs > under the use case they implemented. We can argue that internal versioning is > needed in 100% of the implementations while cross-system is a much less > implemented case. This doesn't mean that the current specs are not usable and > useful in abstract, but we should contextualize the discussion by use case > and by the frequency each is implemented. > > For internal versioning it is clear that distributed versioning spec > generate some friction at implementation time. IMO we need to address both > use cases trying to minimize friction for new developers. That can improve > the quality of the specs without print anything out. > > Also, I would like to hear more about implementations of both use cases and > the challenges implementers had to really validate the idea of addressing > both use cases explicitly in the specs. > > Cheers, > Pablo. > ___ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
