ACTIVITY.timing spec needs more definition and XSD should allow complex timing.value
Description
Attachments
PR is addressed in
Activity
this was already fixed in RM 1.0.4, see CRs
@Thomas it would be wonderful to defined timing in the RM. IMO we might need to support some current models, some current expressions, and maybe come up with glue model and expression from openEHR. I don't think we need to generate a totally new model/expression.
Also suggest usage of those for each context, since some expressions are great for medication but not for other areas, from a regular frequency in a period, to irregular patterns of events that are intervals instead of points in time .
And I mentioned models/expressions, since some structural models are more suitable for some areas, but some expressions are better for other areas. Also considering both to give some constrained alternatives to developers, instead of imposing one model or expression.
Considering development, models can be easily mapped to user interfaces, where instances of timing can be defined. For expressions, some kind of user interfaces should be created to define the expression, like a cron builder. In the RM the expression is easier to manage, store and communicate, since it is one string that complies with a regex. For the model, we'll have many classes, and need to define the serialization for data query results, data commit, and data interchange.
It would be awesome if we can join FHIR on this effort to create something both can use, and solve the problem for good.
@Ian McNicoll I presume what you mean in the last para is that its tricky when dose may change for sections of time? This is clearly common in chemo regimes, e.g. 4 weeks x Med combo A, 2 weeks x Med combo B... and I guess even in simple things.
I told Grahame I think we all have incoherent time modelling, including FHIR, and he agreed - he's raised it as an issue in the FHIR community to develop some algorithms for determining if a given (FHIR) time def has been reached at any given clock moment, and also for what data capture and display screens would look like. I think it's about the same job for us, and I don't think it's easily doable without a more coherent model of time.
Agree of course on proving the archetypes, but I think we need to perform a parallel activity. This has been a bad area for years, we need to fix it...
I'd have absolutely no problem with timing being incorporated into the RM in a more concise formalism than the structural approach that the archetypes, of course, must use. However I would suggest that it would be much better for now to stress-test the timing archetypes in production for a while. We can extend /adapt the archetypes much more easily than RM change and apply / test them to different host settings, imaging, procedure timings etc so that we know we have a solid model before enshrining in the RM.
Scheduled timings e.g. as timed tasks is a little different since this is much more readily handled by typical calendar-type timings. It is when details of the task (e.g. dosage) get intimately connected with an instruction timing that things get complex.
The attachments show what kinds of things people are thinking about, but the models are mostly incoherent - just bags of attributes. I think we need to model this properly.
Details
Details
Reporter
Components
Affects versions
Priority
Major
ACTIVITY.timing : DV_PARSABLE is a mandatory attribute.
The definition is "Timing of the activity, in the form of a parsable string, such as an HL7 GTS or ISO8601 string."
http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_activity_class
1. Should it be mandatory even if the system generating the data doesn't have/can't generate a structured/parsable timing?
2. When frequencies and durations need to be specified in a GTS expression, that is not a parsable string, is a complex XML structure. Trying to put that on the XML gives an XSD validation error since the ACTIVITY.timing.value is string (simple type) and the content is complex.
http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_parsable_class
3. The issue on 2. also happens with DV_TIME_SPECIFICATION.value : DV_PARSABLE "The specification, in the HL7v3 syntax for PIVL or EIVL types.". The syntax is XML and that content is not allowed on a string (DV_PARSABLE.value).
http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_time_specification_class
4. Points 2 and 3 are related to ITS, but the issue comes from the IM.
5. The spec definition for DV_PARSABLE.value is insufficient to understand how to use it, and examples are needed.
Some ideas:
For 1. make the timing attribute optional.
For 2. while at the IM level, DV_PARSABLE.value can store the XML for GTS, PIVL, EIVL, etc., at the XSD level if the type of DV_PARSABLE is string, the XML can't be stored in a XML composition instance.
An idea is to change the type of DV_PARSABLE.value from:
<xs:element name="value" type="xs:string"/>
To:
<xs:element name="value" type="AllowAny"/>
<xs:complexType name="AllowAny" mixed="true">
<xs:sequence>
<xs:any minOccurs="0"/>
</xs:sequence>
</xs:complexType>
That allows content like (I tested this and work OK):
<value>sdfgsdfgsfg</value>
OR
<value>
{
"effectiveTime": {
"_xsi:type": "PIVL_TS",
"period": {
"_value": 12,
"_unit": "h"
}
}
}
</value>
OR
<value>
<effectiveTime xsi:type="PIVL_TS">
<period value="12" unit="h"/>
</effectiveTime>
</value>
That last one, is using the "any" from the XSD and require that the PIVL_TS is declared in a referenced XSD. The HL7 v3 XSD can be used to resolve the type.
That solution doesn't change the IM, allows extensions at the XSD level to use any formalism based on XML to represent the parsable expression, but makes the XSD to look different than the IM (not really an issue since those represent different things).