Presentation is loading. Please wait.

Presentation is loading. Please wait.

EHR Standards Project DSTU Basic Observations Professional Service July 05, 2006 Webcast.

Similar presentations


Presentation on theme: "EHR Standards Project DSTU Basic Observations Professional Service July 05, 2006 Webcast."— Presentation transcript:

1 EHR Standards Project DSTU Basic Observations Professional Service July 05, 2006 Webcast

2 © 2006, Canada Health Infoway, Inc. 2 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. 3 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. 4 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. 5 Professional Services Common Observations Common Observation, Professional Services DSTU DSTU

6 © 2006, Canada Health Infoway, Inc. 6 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. 7 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. 8 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. 9 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. 10 Professional Service

11 © 2006, Canada Health Infoway, Inc. 11 Common Observation

12 © 2006, Canada Health Infoway, Inc. 12 Naming Issue: Care Provision EHR Action Clinical Conditions Health ConditionSuggest going with “Health Condition” as most general.

13 © 2006, Canada Health Infoway, Inc. 13 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. 14 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. 15 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. 16 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. 17 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. 18 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. 19 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. 20 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. 21 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. 22 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. 23 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. 24 …thank you


Download ppt "EHR Standards Project DSTU Basic Observations Professional Service July 05, 2006 Webcast."

Similar presentations


Ads by Google