EHR Standards Project

DSTU Basic ObservationsProfessional Service

July 05, 2006

Webcast

2

© 2006, Canada Health Infoway, Inc.

• To move Draft for Comment Topics to DSTU level – Basic Observations– Professional Services

• for the September Ballot

Presentation Objectives

3

© 2006, Canada Health Infoway, Inc.

Presentation Overview

• Care Provision domain ballot diagram• Procedure overview• Common observation overview• Gap analysis• Procedure model• Common observation model• Review specifics:

– Naming– Replaced Records– Replacing Record– Notes Indicator

4

© 2006, Canada Health Infoway, Inc.

Presentation Overview

• Review cont.– Reporter– Request

• Request ID• Request Type• Requesting Provider

– EHR Repository– Care Composition– Categories– describes incident– has Component Observation

• Component Observation Type• Component Observation Value

– Service Report Reference Id

5

© 2006, Canada Health Infoway, Inc.

Professional Services

Common Observations

Common Observation, Professional Services DSTU

DSTU

6

© 2006, Canada Health Infoway, Inc.

Care Provision Ballot Topic: Professionals Services• Ballot contains cognitive services performed

– Examples; education, training, smoking cessation

• Adding in physical service performed

– Involving direct physical manipulation or modification of the patient – Examples; such as surgery, physical therapy, etc.

Procedure

7

© 2006, Canada Health Infoway, Inc.

Common Observation

Care Provision Ballot Topic: Basic Observations

• Ballot contains simple measured clinical observations – Examples are: height, weight, blood-pressure, temperature

• Adding in Coded Observations – Involving additional messages to support coded observations– Examples: APGAR score, symptom, blood type, smoker, etc.

8

© 2006, Canada Health Infoway, Inc.

Gap Analysis

Id

Code

Status

Uncertainty

Negation

Confidentiality

Effective Time

Replaced Records

Replacing Record

Notes Indicator

Patient

Author

Author Time

Supervisor

Reporter

Performer

Request–Request Id–Request Type–Requesting provider

Record Location

Service Location

EHR Repository

Care Compositions

Indications

Notes

9

© 2006, Canada Health Infoway, Inc.

Gap Analysis cont.

Professional Service

Service Categories 

Anatomical Locations 

Anatomical Location Approaches 

Service Report Reference Id 

Common Observation

Observation Categories

Anatomical Locations

Observation Value

Observation Normality Interpretation 

Observation Severity

  describes incident at Location

 has Component Observations– Component Observation Type – Component Observation Value 

10

© 2006, Canada Health Infoway, Inc.Professional Service

11

© 2006, Canada Health Infoway, Inc.Common Observation

12

© 2006, Canada Health Infoway, Inc.

Naming

• Issue:

Care Provision EHR

• Action

Clinical Conditions

Health Condition Suggest going with “Health Condition” as most general.

13

© 2006, Canada Health Infoway, Inc.

Replaced Records

Requirement: To be able to identify records the old records.– R (1..1)– Need ActRelationship successor.typeCode = SUCC typeCode to point both

directions, which will allow merging of records

• Used to identify any records that are "superseded" by the current record. This will cause the referenced records to be marked as "obsolete" with a reference pointing to this record.

• A way of dealing with information initially captured that is erroneous, incomplete or not captured at the desired level of detail and the change cannot be made by retracting the original record.

• May also be used to reference multiple records.

Action: The successor is represented by the (PERT)….; we need to represent the other end of it .as a <=SEQL relationship in the other direction .

(predecessor.oldProcedureEvent.id) (predecessor.oldCommonObservationEvent.id)

14

© 2006, Canada Health Infoway, Inc.

Replacing Record

Requirement: To be able to identify the new record.

EHR– R (1..1)– Need ActRelationship precedessor.typeCode = SUCC typeCode to point both directions to

allow merging of records

• Used to identify the record which supersedes the current record.• Used in circumstances where a newer or corrected version of the record of this event

exits.

Care Provision– (0..*) ActRelationship pertinentInformation3.typeCode: PREV – A relationship in which the target Care Provision act is a predecessor instance to the

source Care Provision act. Generally each of these instances is similar, but not identical.

Action:

(successor.newProcedureEvent.id) (successor.newCommonObservationEvent.id)

15

© 2006, Canada Health Infoway, Inc.

Notes Indicator

Requirement: To positively know whether notes are available or not.– M (1..1) BL

• Provides an indication that there are notes associated with the procedure / observation record.

• Used to show whether additional information is available on further drill-down.

• Used in summary responses.

Action: Add ActRelationship.subSet on the targetOf on the CareS tatement choicebox to cover the specifying of ‘Notes Indicator’

(subjectOf2.annotationIndicator) (subjectOf4.annotationIndicator)

16

© 2006, Canada Health Infoway, Inc.

Reporter

Requirement: To be able to identify who reported the problem.– R (0..1)

• In the case where the information in the record is being captured second-hand, identifies the source of the information.

• To be able to understand the source of data, which is essential to its interpretation. It can be very valuable to include information in the EHR that has been reported to the recording provider by the patient, patient's relative or other person. However, it is equally important that such information be clearly distinguished from information of which the provider has a first-hand awareness.

Action: The D-MIM in PatientCare should just use the Agency CMET; should be [0..*] (iEHR’s Informant CMET would then simply be a constrained version)

(informant.personalRelationship)

17

© 2006, Canada Health Infoway, Inc.

Request

Requirement: An event model with a reference to a request.

• This references the request (referral or specific request) which resulted in the creation of the procedure / observation.

• Attributes– Request Id– Request Type– Requesting Provider

Action: This structure should be replicated on all of the PC Topics/Models; should be [0..*]

(inFulfillmentOf.actRequest)

18

© 2006, Canada Health Infoway, Inc.

EHR Repository

Requirement: To identify the EHR infostructure responsible for the storage and management of the record.

• Provides context about the record and its management.• Attributes

– Repository Jurisdiction Name –  Repository Name –  Repository URL 

Action: The international version should have cardinality of [0..1]

(AssignedDevice)

19

© 2006, Canada Health Infoway, Inc.

Care Compositions

Requirement: To link records to encounters, episodes and other care compositions.

• A care composition is a record, which summarizes the events that happened during care including who is responsible for the care provided. Examples include encounters, episodes and general "care events" such as "gynecological care".

• Useful for searching and navigation of the patient's record. • Attributes

– Care Composition Type • Emergency Encounter", "Long Term Care Encounter", "Episode", etc.

– Care Composition Identifier • Unique identifier of an encounter, episode or other care event.

Action: Re-think the use of ‘CST’ for the EHR Repository

(PatientCareProvisionEvent)

20

© 2006, Canada Health Infoway, Inc.

Observation Categories / Service Categories

Requirement: To describe the categorization of the observation / service. E.g. Psychological Counseling, Smoking Cessation, Cardiac Surgeries, etc.

• Allows for categorizing of common observations / professional services for presentation. A given person may have had numerous observations / procedures related to a particular area. Allows for drill down to the specific observation / procedures.

• The presence of this field is essential to prevent users from being

overwhelmed, however not all services will necessarily be categorizable. Therefore this element is marked as 'populated'.

Action: This ‘WorkingList’ structure must go on the PC D-MIM as [0..*]. At the universal level, there should be priorityNumber

(componentOf.workingListEvent.code) (componentOf1.workingListEvent.code)

21

© 2006, Canada Health Infoway, Inc.

  describes incident at Location

Requirement: To indicate the actual location where the incident described by the observation took place. E.g. site of accident, location of patient at time of cardiac arrest, location when subjected to exposure to a virus.

• The location of the actual 'event' captured by an observation may differ from the place where the observation was actually made. The location of the incident may provide context to a patient's condition. The information may also be of interest from a public health perspective.

Action: This should be added to the PC D-MIM ;

(indirectTarget.location)

22

© 2006, Canada Health Infoway, Inc.

 has Component Observations 

Requirement: To indicate sub-observations that combine to make up the overall observation.

• Needed for more complex observations such as Glasgow Coma Scores, APGAR Scores, blood pressure, etc.

• Attributes– Component Observation Type – Component Observation Value

Action:

(component.subObservationEvent)

23

© 2006, Canada Health Infoway, Inc.

Service Report Reference Id  

Requirement: An identifier for a report associated with the procedure.

• Allows for a direct link to a report that has been written on the procedure.

Action: The recursive relationship on the DMIM covers this; we should cover this in the PC RMIMs

(subjectOf3.documentEvent.id)

24

© 2006, Canada Health Infoway, Inc.

…thank you