Requirement to message Problem Structures as found in UK clinical systems

Summary requirements for UK style Problem structures

This documents usage of problem structures in existing UK clinical systems :

• Problems are headings that a Problem list can made from, and that organize the medical record.
• Problems have members, which are linked to and are part of the overall problem.
• a Problem heading is a grouper of other statements (its members).
• a Membership relation between a problem and its member implies nothing other than that, well known, relationship.
• A Problem has a single naming/header statement which can change over time.
• Names and other members are clinical statements in their own right.
• a Problem can have anything as a member (any statement, more or less), including other Problems.
• a Problem as whole can be current or dormant (active or inactive).
• Being on the Problem list doesn't necessarily imply that management or active monitoring is needed, although it often will.
• A Problem may or may not appear to be a "problem" to the patient.
• Membership relationships shouldn't preclude other relationships such as "caused by" existing in addition.

In relation to underlying condition :

• The status of the Problem doesn't necessarily imply that the underlying condition, if any, has the same status, although it would normally reflect that.

• A Problem may have no underlying condition in the medical sense; sometimes Problems are just administrative headings eg. "Immunisations" or even "Letters to Patient" (based on common use, not best practice).

Some supplementary requirements that relate to messaging of problems and storing them centrally :

• Authorship of an individual Problem's structure can be by several authors in different message instances.
• There should be no need to send the entire problem (less so the entire problem list) to add or remove a name or other member from that problem.
• Assertion of membership or names of problems in a shared record system is itself an act of clinical authorship and must be attributable and updatable.

Full Requirements

The UK has a large amount of clinically coded data in general practice systems, where computerisation is close to 100%.

Much of the data is organised by simple "problem headings".

This generally involves promoting one clinical entry in the otherwise flat record structure to be the "parent" of other records.

Not all data in the UK is in primary care records of course, but much is, and so this structure must be supported in messages.

GP systems vary in capabilities, but there are some common features.

The record as a whole tends to have a flat structure (eg. a table full of records, each with a clinical code) apart from :

• Encounters have records temporally relating to them, as their children.

• Problems have records directly relating to them, judged by any criteria the author chooses, as children ("problem members").

• Medication can be structured so that authorisations for repeat medication act as parents for individual issues of that medication.

The focus here is on the middle of those three.

Problem Structures

This style of structure is is created totally at the clinician's discretion. Any grouping can be expressed here, and the semantic is purely one of grouping under a problem heading. The grouped items tends to be called "members", hence the relationship is one of "problem membership". This has its own inherent meaning, and is meant to approximate the Problem Oriented Medical Record, after Weed.

This structure is not intended for decision support, nor for the meaning to be interpreted by a machine. It's for human support, to summarise and make the record easier to read and navigate. It must be preserved when the data is transmitted.

A problem in the record doesn't necessarily imply a problem for the patient, so the word "problem" has the usual difficulties in that respect, but nevertheless that's what they are known as. In most cases "Record heading" could probably be used to describe the same thing. A key issue is that this heading is itself one of the medical records.

To the user the problem heading record is just one of the individual medical record entries that they have decided to say is a "problem". In practice each record in the database may have an "is problem" flag. Other records have a "parent problem id" field which would have the problem heading id as a foreign key. In some systems a record can be a member of several problems, so some form of linkages table would be employed to allow many to many relationships.

The problem heading itself is identical to any other record except for its "problem flag" and also there is generally a "current" or "dormant" flag too.

A set of several problems would be a problem list. There is little extra structure to this, it is just "all the problems", and it would typically be computed at runtime in a relational database based system. There are typically two problem lists, current and dormant, that show all the problem headings with those two statuses.

The problem as a whole is the problem heading plus all the other statements directly associated with it as members. Many of those members will have additional relationships to encounters or as part of a medication structure.

The problem heading is a placeholder for the whole structure. It acts as the name for the problem, and as stated, its only specific properties are that it is a heading, and it is current or dormant. As a clinical statement it will have times and authors too.

Representation of Problem Name

It would be possible for a problem to be represented by an unnamed grouper to which other records are attached, one of which acts as its name.

In practice, there may be no unnamed grouper, and the record that's made into the heading acts as both the grouper and the name. Thus the authorship and times of this statement are adopted by the problem as a whole. However people don't tend to view this statement in isolation, so other authors and timings on the child statements will generally be considered.

This means that the lack of an individual set of attributes for the problem as a group and the problem header statement isn't an issue in the UK. The only property the group has is "problemness" and "current/dormant status". (These may be implemented as attributes on every record in the system, and the status field is just unused if the record isn't used as a header.)

Renaming

One thing that tends to happens with problems, is that the header statement gets replaced with another more accurate one, as the information on the condition is discovered, or as the condition develops and changes.

At this point a different record is chosen as the problem header and all the children are moved underneath it, by some automatic process, during which the original header may be relagated to be a member of the new header. Conceptually this is a renaming of the problem, although in fact the implementation may not directly support the concept of a name.

Renaming is really a "replacement of header statement". Since this happens a lot, a cleaner implementation could be to have the naming statement separate from the grouping statement. The split between namer and grouper is not something that the user of a problem based system would generally relate to. They just see clinical records that are used as headers, by an established convention.

Relationships

It is true that the relationship between a problem heading and its members is clinically quite vague.

There is no sense of the relationships commonly found in HL7 eg reasons, causes, has support for etc.

A human will tend to infer some of these things however. They may see a finding and assume it was recorded under the problem to indicate support for diagnosis, or as part of a monitoring plan. They might see medication attached to a problem and infer it was given for the condition that the problem is about. They wouldn't tend to infer that the condition was caused by the medication. One would assume that the clinician would add a more specific record to indicate if that was the case. It is true that a machine cannot know if the medication is the cause or the treatment. This interpretation is no more or less accurate that if multiple records in a linear list of entries were viewed and interpreted by a human or machine.

Clearly, it would be good if concepts such as cause and reason were able to be applied between problems and their members, or between any pairs of entries in the medical records.

This isn't generally possible in current generation system, even though HL7 supports this well. The requirement here is to reproduce in messages what can be done by current systems, rather than to design the best way these systems could have been implemented. Also the implementation should not preclude more advanced features being added in future, or that are already supported by different systems.

Although the problem links are imprecise it is important to be able to preserve the problem memberships that a clinician took the time to author. Problems are, as is well known, a valuable way to organise the medical record, and the simplistic problem structures used in the UK are very popular with users.

Digression to potential solutions for membership relations:

It is thought that the problem membership linkage must be represented in a way that cannot be confused with other linkages that HL7 may support. For instance if SPRT is used to link problems to their members then it won't be possible to use SPRT to show support between individual members of the problem. Existing SPRT relationships could be misinterpretation as relating to problems or condition tracking.

Membership could possibly be represented by a unique combination of classCode and an existing actRelationship type (eg. CONC+(COMP or NAME) ).

It also is possible that a statement in a message may have an "is member" relation with its problem heading as well as wanting (in a system of suitable capability) a "has support" or "caused by" relationship. Here two or more act relationships may be needed. To avoid restating statements this seems to imply a messaging solution involving actRefs.

Requirements for shared Problems

With the proposed move to centralised records in the UK there is a requirement for these problems to be shared and updated by multiple clinicians. It would certainly be helpful if it was possible to make an update to a problem structure without needing to restate the entire problem and all its members. This would be verbose and could end up implying that all the clinical statements in the were being re-asserted by the person restating the problem.

On occasion a problem list will be re-organised by a clinician, who may move statements around between problems without authoring any new clinical statements. It should be possible to express this reordered view without it being seen that the clinician is the original author of all the statements that he moved around.