Medical report about improvement system for practical issues, a computer related task or function in an area of healthcare that is relevant

Sample : System and Functional Data Points

Test Recommendations for unusual conditions

Business Case

When a doctor suspects a patient has an unusual diagnosis they may order many tests, some of which might not be the most appropriate for that condition. This software application will identify the tests appropriate for unusual conditions and provide this advice directly to doctors when they are ordering tests for the patient. This process is intended to improve patient care, and reduce diagnostic services test costs.

Objectives

· To advise the doctor when ordering tests of those tests most likely to be effective for potential conditions which are unusual

· To reduce unnecessary tests

· To more quickly obtain results which can improve health through reducing tests which are unlikely to give useful results.

Out of Scope

Login, access, security and privacy requirements are not addressed in this document, it is assumed that any system will have appropriate infrastructure to meet legal requirements and consumer expectations.

Interfaces

This system must be able to interface to the healthcare clinical system, identity management and if possibly alert and alergy information.

Functionality

Trigger Advice

When a clinician enters an order, review the rules established for the system and provide guidance. The system should provide guidance, or if it is not operational should inform the clinician that guidance is not available when they login.

· Data

· Problem, provisional diagnosis of the patient - this should be automatically available from the healthrecord

· Age- of the patient - this should also be available from the health record

· Clinician - automatically provided from login information

· Rules - stored not captured for the individual

· Knowledge - including sources and relevant article links if appropriate

· Warning level (used to inform and for the system to manage risk when advice is ignored or acted against).

Provide Advice

Advice provided when the individual patient instance of data meet the rule details. The knowledge is obtained from the stored information for each specific rules. The advice may be specific for a clinician (recognising that different clinicians may or may not need the advice provided to limit warning fatigue). From advice the user should be able to select tests advised, and record comments / actions (including ignoring advice).

· Data

· Advice - tests recommented, tests optional, tests proven to have little/no value or risk

· Knowledge details (so that the clinician can look up more information to assist with decision making if needed.

· Action taken

Enter Rules

The ability to enter new rules is required to underpin the trigger of advice. The system should display existing rules associated with the problem, provisional diagnosis to make it easier not to duplicate information.

· Data

· Rule identifier

· Condition code (and potentially instructions)

· Age Range Low

· Age Range High

· Age type (day or year or month)

· Clinician

· Recommended test/s

· Potential test/s (not recommended)

· Tests not recommended

· Knowledge source

· Warning Level

· Reference

· Last updated

· Approved by.

Maintain rules and knowledge

Search for a rule - search by condition or by identifier

· Data

· Rule identifier

· Condition code

Display of matching rules

Display of rules that match search criteriaThis display shows all data, present and past for the individual. It supports questions such as have you ever lived at…… From this point you should be able to return to search criteria, select a rule to modify Comment by Main Office HG: Note it would be more effective to use this search for adding as well as maintaining…..

· Data

· All data for the rule

· Date of change

· Effective date of change

· Rationale for change

Export of rules and knowledge

A file containing rules and knowledge should be able to be produced for clinical governance review. Thhis should include all data held in the rules and knowledge system

Export of actions taken to advice

Ability to query advice taken to support peer review.

Data Map

The mind map below indicates the scope of data required to support this clinical decision support system.

Data Definitions

This system will require detailed data definitions for each data item in the map. Three examples are provided here.

Patient Condition

This data element represents the disease or diseases the patient currently has.

Standards for this data element exist widely by many names, diagnosis, problem etc. the following standards were reviewed for suitability AIHW METeOR (the Australian Metadata Online Registry), HL7 FHIR, and OpenEHR Clinical Knowledge Manager (CKM).

METeOR includes definitions of diagnostic elements such as principal diagnosis, additional diagnosis. METeOR also includes representations of medical condition for disability reporting, and emergency cepartment stay, principal diagnosise. These are very specific use cases which do not suit clinical requirements. Data is represented using ICD which aggregates conditions and may not be specific enough to meet the needs for test guidance.

FHIR includes a concept “condition” which is similar to the requirements here but is not specified in detail and offers only a sample of the value domain which could be used. This standard does use SNOMED CT which is a suitable code system for representation of the concepts needed. The use of SNOMED CT AU problems and diagnosis subset would be a suitable value domain (Code system subset).

Definition: state of abnormal health of an individual requiring a test to be performed to evaluate the presence, absence or severity of the condition.

Note: this infomration is used to inform treatment options for the patient.

OpenEHR CKM includes a well defined cluster of data elements which represent condition. See: https://www.openehr.org/ckm/archetypes/1013.1.169

These definitions have been used as the basis for Patient Condition

Value Domain: SNOMED CT AU (coded value) - Problem/Diagnosis Subset.

Recommended Test

This data element represents the test or tests which are ‘approved’ or recommended for this .

Standards for this data element exist for defining tests. These were evaluated to serve as the basis for this data element. The following standards were reviewed for suitability AIHW METeOR (the Australian Metadata Online Registry), HL7 FHIR, and OpenEHR Clinical Knowledge Manager (CKM).

METeOR

No suitable representation was found. METeOR has many definitions of tests but each is defined as a separate data element which would not allow a generic design or ongoing implementation or maintenance of the rules or system which requires a consistent representation for any type of test. Not appropriate for this use case.

HL7 FHIR

The definition in FHIR is well specified from a technical perspetive but provides little guidance for its collection and use. The code system used is LOINC which would suite the use case well.

https://www.hl7.org/fhir/valueset-report-codes.html

OpenEHR CKM

A Test includes a wide range of data elements – in this instance we are only trying to identify the specific test. The specification of test name indicates that this item can and should be coded using LOINC. The specification includes test panels (groups of tests performed together), this will suite the use case of this functionality. Note there is a whole cluster of data elements available for this this case we are only trying to identify the specific test or group of tests required.

https://www.openehr.org/ckm/archetypes/1013.1.2387

https://www.openehr.org/ckm/archetypes/1013.1.2191

OpenEHR CKM was chosen as it was more suitable for the use case of explaining the data to be collected, the concept can be used in conjunction with FHIR resource when information exchange occurse provided the value set (code system) remains the same.

Definition: test recommended to evaluate or monitor a patient with this condition.

Value Domain: LOINC

Approved by

This data element indicates the identification of the organisation or individual who approved these rules for use.

Note: it is intended that the system use the national provider identifiers rather than create a new data element to represent this information. By making this choice it is not necessary to manage the identifiers as this is done nationally.

METeOR

The national identifiers for providers and organisations are available and well defined in METeOR, HL7 FHIR and OpenEHR CKM define these identifiers generically. Use of the METeor Definition provides all the infomration required for practi al implementation.

There is a problem that the individual provider identifier and the organisation identifier are two different identifiers. This will mean that authorised by will be come two different fields and at last one of these must be included.

Provider Organisation Identifier: https://meteor.aihw.gov.au/content/index.phtml/itemId/495953

Definition: unique identifier assigned to a swervice provider organisation (agency)

Provider Identifier – Healthcare individual provider identifier https://meteor.aihw.gov.au/content/index.phtml/itemId/522896

Definition: persistent identifier issued by a registration body to identify an individual service provider.

Issues

· The rules need to be developed and clinically safe. This will need input from relevant clinicians and diagnostic services experts. It would be ideal if the relevant clinical professional bodies created and monitored the rules for use for the whole country or more broadly.

· Determine the exact range of the data elements to be included.