UpdateTime proposal

These issues are within scope of the INM Committee and are still being discussed. Once resolved they will be included in an INM ballot.

Introduction

There is a requirement to be able to manage distributed updates between intermittently connected systems using timestamps to identify the most recently updated version of the information conveyed.

It is recognised that this approach is problematic because of the need to synchronise system clocks across systems. However it is an approach that is commonly used, and so should be supported by HL7 communication specifications.

Use cases

The Screening domain Management Service endpoints have been experiencing AgentUpdate and PatientUpdate conflict resolution problems. It is common for ‘out of date’ AgentUpdate/ PatientUpdate messages transferred from an intermittently connected remote system to overwrite the current agent/ patient data on the management system.

There are 2 use cases:

(1) PatientUpdate

Supporting distributed changes to demographic information, where the patient address, telephone numbers and registered physicians can be changed independently in different locations and computer systems.

(2) AgentUpdate

Supporting distributed changes to agent information, where the agent name and address can be changed independently in different locations and computer systems.

The AgentUpdate message specified in the Screening domain contains information recorded about all of the Agents (healthcare professionals, organisations and devices) that are involved in the care of the patient. The AgentUpdate message should be used where the agent role is not defined on SDS.

The below use case description covers the AgentUpdate and PatientUpdate interactions within a screening completed trigger event. The ScreeningCompleted use case is not described in detail as we are only interested in the AgentUpdate and PatientUpdate interactions. Only the functionality required in order to assess the information transferred for this purpose is therefore described.

Use Case:

It’s Monday morning and Steve Wynne a mobile screener has arrived at Newlybuilt Medical Centre and set up his equipment in Dr Holiday's room. His laptop is coupled to the non-mydriatic camera and he is ready to screen. As each patient arrives, he gets consent to hold their information and records it. If the patient's data differs from that on file, it will trigger a DemographicsUpdated event, likewise for a patient’s agent details. He then takes the retinal images. He has to record visual acuity and some other basic information but doesn't interpret or grade the pictures. If he is certain that a patient is not going to attend, he will record that against that screening appointment instead.

After each patient episode Steve Wynne clicks the screening episode completed button. This activates the ScreeningCompleted event trigger which caches messages on the laptop to include either (1) successful screening data and patient images (URL references) or (2) details of a patient DNA, ready for transfer back to the Management Service.

At stumps on Friday afternoon, Steve returns to the Nearlyperfect Screening Service office. Sally Piucci connects Steve’s laptop to the network and all the screening records for the week are uploaded into grading queue on the central Management Service computer. The following messages are sent for all patient episodes; PatientUpdate, ScreeningReport and AgentUpdate. There must be at least a [2...*] AgentUpdate messages within each ScreeningCompleted conversation. The mandatory Agent messages are AgentOrganisation and AgentPerson, but could also include and AgentDevice message. Summarised as below:

• Organisation – initiating system will provide a [1..2] national code for the organization

• Person - healthcare professional will provide a [1..2] identifier

• Device - EHR application device will provide a [1..2] unique identifier

The AgentPerson payload must provide at least one name of the person [1..2], [0..5] telecom and [0..2] address details. A new timestamp conflict resolution functionality is required to identify the most recently updated versions of the information conveyed within this payload.

The AgentOrganisation payload has a [0..1] name of the organisation, a [0..5] telecom and a [0..2] address. The AgentDevice payload has a [0...1] name of device. Again, new timestamp conflict resolution functionality is required to identify the most recently updated versions of the information conveyed within this payload. However, the organisation and device agents are not going to need updating as frequently as the AgentPerson payload.

Finally, the PatientUpdate payload must also provide a [1..1] patient identifier and healthcare provider, [0..*] name, telecom and address details and a [0..1] birthtime. As for the AgentUpdate messages new timestamp conflict resolution functionality is required to identify the most recently updated versions of the information conveyed within this payload.

Existing HL7 solutions

This timestamp information may be modelled as the controlAct.author.time.high for the most recent control act that applies to the information item in question.

One approach is to say that a separate communication (message / SOA method / Document) should be used for each change to an independent piece of information. This is impractical.

An alternate approach is to say that the controlActs should be conveyed with a "subject" actRelationship off the focal act of the payload. The datatypes R2 HIXT.controlActRef would be used to point from an HL7 attribute (such as an address or telephone number) to the controlAct that triggered the most recent change or verification of that information.

Proposed Solution

Add a new updateMode 'code' of "V" (Verified) to be used in situations where the data is unchanged but has been actively confirmed by the author.

Add an updateTime property to all attributes (via ANY) and associations (via InfrastructureRoot) as a 'parallel' to updateMode with a constraint that it must be identical to the ControlAct.author.time of the ControlAct resolved to by ControlActIdRef, if any.

Motion 20070803: MnM endorses the above approach and directs Charlie McKay to submit the necessary datatype change and harmonization proposal Moved: Charlie/Lee - 6/0/0

The following is an example of the use of updateTime in comparison to the controlAct.author.time method using a small healthcare agent update message:

ControlAct.author.time approach:

<AgentRole>
	<component>
		<agentControlAct>
			<id root="12712829-7ED7-76AD-13ED-125621EDA72C"/>
			<author>
				<time value="200603121432"/>
				<agent nullFlavor="NI"/>
			</author>
		</agentControlAct>
	</component>
	<id root="ADFEE4FB-1375-7443-8755-F43ED798BC62"/>
	<code codeSystem="2.16.840.1.113883.2.1.6.18.53" code="04" displayName="Retinal grader"/>
	<agentPerson>
		<id root="2.16.840.1.113883.2.1.4.7.12" extension="CHES02"/>
		<name>
			John Cholmondly-Warner
			<controlActIdRef root="12712829-7ED7-76AD-13ED-125621EDA72C"/>
		</name>
	</agentPerson>
</AgentRole>

updateTime approach:

<AgentRole>
	<id root="ADFEE4FB-1375-7443-8755-F43ED798BC62"/>
	<code codeSystem="2.16.840.1.113883.2.1.6.18.53" code="04" displayName="Retinal grader"/>
	<agentPerson>
		<id root="2.16.840.1.113883.2.1.4.7.12" extension="CHES02"/>
		<name updateTime="20030809123412">
			John Cholmondly-Warner
		</name>
	</agentPerson>
</AgentRole>