I am currently merging the Timing daily and non-daily archetypes into a single unified archetype. This effort aims to align closer with the FHIR Timing backbone element and enhance functionality for machine-to-machine communication, adhering to IETF standards.
The goal of this refactoring is to assess the benefits and drawbacks compared to the existing specifications. However, I’m encountering an issue with defining frequency units such as 1/s (second), 1/min (minute), 1/h (hour), 1/d (day), 1/wk (week), 1/mo (month), and 1/yr (year) in the merged “Frequency” attribute. Despite searching through all available units and utilizing the search function, I cannot locate these specific units. I attempted to copy the “Frequency” attribute from the Timing daily archetype and then integrate additional units from Timing non-daily, but this has not been successful, as illustrated in the snapshot below:
Hi Lucas! I’m looking forward to seeing the results of your work.
The original reasoning behind modelling timing as a set of archetypes was to enable every use case from the simplest to the most complex, without making each archetype too complex to understand (or model!). This set includes not only the two archetypes for timing within and outside a 24h period of time, but also dosage and therapeutic direction, as well as service direction which came later.
Regarding your specific question, in AD you will probably need to use the {QUALIFIED REAL/TIME} metaunit, which allows you to construct your own UCUM units using the available units for those two properties.
Thank you so much, for your input, Silje. You spared me from an unsurmountable amount of work. I am so happy, that I can now include the missing units.
I’ll also be interested in your conclusions @lukas.eksteen .
The current archetypes are complex but the have been well road-tested by both GP community prescribing use and by inpatient use, which have slightly different requirements.
I’ve had a look at the current FHIR Timings datatype and I think the main difference is that we explicitly split timings into ‘daily’ and ‘non-daily’ and although I’ve no problem in principle with getting closer alignment to FHIR timings, I can see a few use cases where the FHIR timings would not cope well with opmore complex timings or be just as confusing. e.g. “4 times a day, 3 times per week”.
Have you considered making the frequency element 0…2 to allow both -in-day and non-daily frequencies in the same instructions, or having both in-day frequency and non-daily frequency as separate elements in the unified archetype?
I look at the current requirements in our EHR and what RFC5545 specifies, and based on that, I model the archetype. In a second step, I align it to FHIR to allow an easier mapping onto FHIR, which will represent a subset of the modeled archetype.
Really interested in how you get on
Please keep us posted with examples of your reworked archetype.
I suspect you will find that RFC5545 drives you crazy in this context. This was something that was looked at many years ago.
We came up with the dose and timing model, based on a lot of prior work by HL7, UK CfH and some work by Univ. Dundee which ‘unlocked’ the need to clearly separate daily timing from non-daily timing.
Yep, as well as things like “2 tablets in the morning and 3 at night, on Mondays, Wednesdays and Saturdays” or “apply on affected skin until it glistens in the morning for two weeks, then take a break for two weeks, then start over”.
I have read RFC5545 and it is actually straightforward, but highly boring - reading more than 150 pages may drive you crazy. Moreover, there exist additional RFCs, which should be accounted for (RFC5546, RFC6868, RFC7529, RFC7986, RFC7265) and I have not read it — yet. I hope to finish these novellas in the next two weeks to dive deep into the drama of timings in openEHR.
It is important to note that I differentiate between human to human communication and machine to machine. Many aspects of timing shouldn’t concern a human and be handled by machines. But between machine and humans, the protocol of communication is still a work in progress and until then, machines will display examples such as "4 times a day, 3 times per week” because the machine allowed the human to input such confusing timing patterns - and because the human probably did not know it better, either.
I will keep you posted. And this thread should be considered closed, as the question has been answered by Silje. I will create a new thread about my endeavor, such that the discussion may remain on the subject.
.