Transcript Virtual Medical Record

Virtual Medical Record
HL7 UK 2003
Peter Johnson
©2003 Sowerby Centre for Health Informatics at Newcastle
What is a vMR?
• It’s a standard INTERFACE
• Safe mediation interface between HL7 compliant clinical
systems and decision support systems
• Purpose is DSS task-specific communication
• NOT a persistent record – on the fly translation
• NOT an EHR standard
• Standard names for categories of things found in
records (medical record classes) – e.g. “Investigation”
• NOT a vocabulary – it has < 20 classes
• In HL7 form a set of messages from a DMIM
• Performance guarantees - QoS
©2003 Sowerby Centre for Health Informatics at Newcastle
vMR definition
• define a shared model of "what
structures are possible to query" in a
way that abstract away from
idiosyncrasies of a particular institution's
or vendor's EHR
• plus the messages/events to facilitate
that
©2003 Sowerby Centre for Health Informatics at Newcastle
DSS KB
CDSS engine
Uses VMR terms
Events
Action requests
Writes/updates
Queries
API or messages - using VMR objects/attributes/terms
Terminology
Mediation Server
VMR <> host
©2003 Sowerby Centre for Health Informatics at Newcastle
Clinical system adaptor
Clinical
System
Why do we need one?
•
•
•
•
•
Expense of DSS; maximise reuse
No human in the loop
Impedance mismatch
One to Many systems interface issue
Performance guarantees
©2003 Sowerby Centre for Health Informatics at Newcastle
Why? – Expense of DSS
• DSS Knowledge base production very
resource intensive, therefore expensive
• Much of the resource use is in creating logical
expressions about the patient
• e.g. “if diabetic or hasLVF and systolicBP > 135 or
disatolicBP > 85 then…”
• Need to standardise the way these are
written
• Write once, reuse on all systems
©2003 Sowerby Centre for Health Informatics at Newcastle
Why? – No humans
• Machine to machine communication
here
• No intelligence in AI
• Can’t fudge issues expecting a human
to resolve them
• Everything explicit, minimise ambiguity
©2003 Sowerby Centre for Health Informatics at Newcastle
Why? - Impedance mismatch problem
• DSS to Care Record System has
impedance mismatch
• Record structure mismatch
• Complexity vs. Simplicity
• Terminology mismatch
• Specific vs. General
©2003 Sowerby Centre for Health Informatics at Newcastle
Why? - differing systems problem
One DSS system >> many clinical
systems
• Differing underlying medical record models
• Differing terminology
• Surely HL7 messages makes this go
away?
• Subtle problems remain – differing
institutions use same records/terms to
mean different things
©2003 Sowerby Centre for Health Informatics at Newcastle
Differing medical record models
•
•
•
•
Many different schemata in vendor medical records
Most of their distinctions not relevant to clinical DSS
Drop administrative, audit trail, security distinctions
Define a simplified schemata – a ‘view’
vMR contains a standard simplification of record data-model
•
•
•
•
Surprising success across domains and countries
•
•
•
•
Only distinctions important to clinical decision support
Minimum number of patient-data classes for this task
Minimum number of attributes for this task
UK primary care
US ambulatory care
US secondary care
Based on real experience on real systems
•
UK implementation on Torex; US on VA systems
©2003 Sowerby Centre for Health Informatics at Newcastle
List of relational tables in
one UK clinical system (145; 3-20 fields)
Terminology problem
• Problem 1. Level of specificity
• DSS KB mainly written in generalised/abstraction of term found in
record
• Coded records may be very specific, e.g. ‘prolonged ST interval on
ECG’
• DSS may need only more general ‘risk of heart block’ – satisfiable
by presence of hundreds of coded entries.
• Mapping from specific -> general
• Lessens risk of changed meaning
• vMR defines messages to Terminology Server for these services
• Problem 2. Blurred/variable boundary between
vocab and medical record structure
• e.g. Blood pressure. Is it 3 distinct records with relationships, each
with terms, or is it one term with parts and values
• Other problems e.g. physical units mismatch etc
©2003 Sowerby Centre for Health Informatics at Newcastle
Why? -performance problem
• Interactive DSS requires sub second
responses
• Prodigy guideline system can generate
several hundred queries to bring up one set
of choices between actions – need to be subsecond
• Exacting and technically hard to achieve, and
has to influence the approach taken
• Will HL7 v3 messages work?
• Even harder in WAN environment
• Differences between close-coupled and looselycoupled systems
• Quality of Service guarantees required
©2003 Sowerby Centre for Health Informatics at Newcastle
vMR Aims:
• Unambiguous communication between DSS and EHR
by:
• Standard model of record classes
• Standard names of record classes
• Standard attribute names
• Allow reusable logical expressions to be written
‘…observation.code == ‘SBP’ AND observation.value > 140
AND … assessment.code == ‘Diabetes’ OR assessment.code
== ‘LVF’ OR…’
• Standard set of messages/functions
• Standard process achieving terminology mediation
• Performance/QoS guarantees
©2003 Sowerby Centre for Health Informatics at Newcastle
Work in HL7
• Most work so far on standardising the
simplified record model for queries
• Similarities with GP2GP EHRStatement noted
• Effort at convergence with GP2GP
• While the models may be very similar;
vMR != GP2GP
• Messages different
• QoS guarantees
©2003 Sowerby Centre for Health Informatics at Newcastle
DSS KB
CDSS module
Uses VMR terms
Events
Action requests
Writes/updates
Queries
API - uses VMR objects/attributes/terms
Terminology
Mediation KB
VMR <> host
©2003 Sowerby Centre for Health Informatics at Newcastle
Clinical system adaptor
Clinical
System
•
•
•
•
•
•
•
•
•
Assessment
Intervention
Plan
Observation
Assessment
Assessment
Assessment(DSS)
Assessment
Goal
In a hypertensive patient
on no antihypertensive medication
initiate antihypertensive treatment
at BP > 140/85
if diagnosis of diabetes
OR diagnosis of LVF
OR 10 year CHD risk > 30%.
OR CVS complications present
Aim to keep BP < 130/85.
i.e.‘…observation.code == ‘SBP’ AND
observation.value > 140 AND …
assessment.code == ‘Diabetes’ OR
assessment.code == ‘LVF’ OR…’
E_Patient_organisation
class_cd* <= ORG
determiner_cd*:
<= INSTANCE
A_Ehr_Statement
(EHPO_CM_RM21000)
class_cd* <= 'ROL'
id II [1..1]
0
P_Related_agent
0
type_cd: CS CNE [1..1] <= EhrRelAgentType
0..*
A_Obs_normal
class_cd* <= 'OBS'
mood_cd CS CNE [1..1] 'EVN.CRT'
value: IVL<PQ> [0..1]
txt: ED [0..1]
interpretation_cd CS CNE [0..1] <=EhrInterpret
AR_Normal
type_cd CS CNE [1..1] 'REFV'
A_Ref_plan
class_cd* <= 'OBS'
mood_cd CS CNE [1..1] 'INT'
id II [1..1]
AR_Related_plan
type_cd CS CNE [1..1] <= OUTC,FFIL
0..*
class_cd* <= 'CTXT'
mood_cd: CS CNE [1..1] 'EVN'
level_cd: CV CNE [1..1] <= EhrCompoundLevel
cd: CD CNE [1..1] <=EhrCompoundCode
id: II [1..1]
activity_time: IVL<TS> [1..1]
status_cd: CS CNE [1..1] <=EhrActState
availability_time: TS [1..1]
type_cd CS CNE [1..1] 'SPC'
time TS [0..1]
0..*
A_Observation
P_Specimen
type_cd CS CNE [1..1] 'SPC'
time TS [0..1]
0..*
AR_Attachment
type_cd CS CNE [1..1] 'APND'
0..*
A_Ref
AR_Revises
class_cd* <= 'ACT'
id: II [1..1]
type_cd: CS CNE [1..1] 'UPDT'
class_cd* <= 'SPEC'
id II [1..1]
cd CS [1..1] <=EhrSpecimenType
effective_time [0..1]
P_Subject
type_cd CS CNE [1..1] 'SUBJ'
1..1
E_Specimen
class_cd* <= OBS
mood_cd*: <= EVN
id: II [1..1]
cd: CD CWE [1..1] <= VmrAssessmentCode
txt: ED [0..1]
status_cd: CS CNE [1..1] <= VmrAssessmentState
effective_time: TS [0..1]
activity_time: IVL<TS> [0..1]
availability_time: TS [1..1]
value: ANY [0..1]
interpretation_cd: CS CNE [0..1]
<= VmrInterpretCode
1..1
class_cd* <= 'PSN'
determiner_cd: CS CNE [1..1] <=KIND ,INST
nm: SET<EN> [0..1]
deceased_ind: BL [0..1]
The narrative exists to accomodate EHR information
which is not semantically processable by a computer system.
Information should be presented in this form if:
- it is not semantically processable in the sending system.
- the semantics in the sending system cannot be reliably
represented in the message
- the information has been degradedbecause the recipient system
does not support the semantics of the sending system.
class_cd* <= 'OBS'
mood_cd: CS CNE [1..1] 'INT'
id: II [1..1]
activity_time: IVL<TS> [0..1]
cd: CD CWE [1..1] <= EhrPlanCode
effective_time: TS [0..1]
txt: ED [0..1]
status_cd: CS CNE [1..1] <= EhrActState
availability_time: TS [1..1]
class_cd* <= 'OBS'
mood_cd: CS CNE [1..1] 'ORD'
id: II [1..1]
activity_time: IVL<TS> [0..1]
cd: CD CWE [1..1] <= EhrReferralCode
effective_time: TS [0..1]
txt: ED [0..1]
status_cd: CS CNE [1..1] <= EhrActState
availability_time: TS [1..1]
A_Goal
class_cd* <= OBS
mood_cd*: <= INT
id: II [1..1]
cd: CD CWE [1..1] <= VmrGoalCode
txt: ED [0..1]
status_cd: CS CNE [1..1] <= VmrGoaltState
effective_time: TS [0..1]
activity_time: IVL<TS> [0..1]
availability_time: TS [1..1]
value: ANY [0..1]
interpretation_cd: CS CNE [0..1]
<= VmrInterpretCode
Note:
A plan may contain a number of
Interventions with mood INT (intent)
and a number of committed goals.
status_cd sets whether active, nullified
or obsolete
AR_Committed_goals 0..*
A_Plan
R_Role_ref
0
type_cd CS CNE [1..1] 'RESPROV'
mode_cd: CV CNE [0..1] <= EhrRequestMode
0..1
class_cd* <= 'ROL'
id II [1..1]
0
class_cd* <= 'OBS'
mood_cd CS CNE [1..1] 'EVN'
id: II [1..1]
activity_time: IVL<TS> [0..1]
status_cd: CS CNE [1..1] <= EhrActState
availability_time: TS [1..1]
P_Registration_agent
type_cd CS CNE [1..1] <= EhrRegistAgentType
mode_cd CV CNE [0..1] <= EhrRegistMode
time: IVL<TS> [0..1]
1..*
class_cd* <= PROC
mood_cd*: <= INT+ORD+EVN
id: II [1..1]
cd: CD CWE [1..1] <= VmrOrderProcCode
txt: ED [0..1]
status_cd: CS CNE [1..1] <= VmrOrderProcState
effective_time: TS [0..1]
activity_time: IVL<TS> [0..1]
availability_time: TS [1..1]
R_Role_ref
0
class_cd* <= 'ROL'
id II [1..1]
0
E_Organisation
class_cd* <= ORG
determiner_cd*: <= INSTANCE
A_Referral
class_cd* <= REFR
mood_cd*: <= INT+ORD+EVN
id: II [1..1]
cd: CD CWE [1..1] <= VmrPlanCode
txt: ED [0..1]
status_cd: CS CNE [1..1] <= VmrPlanState
effective_time: TS [0..1]
activity_time: IVL<TS> [0..1]
availability_time: TS [1..1]
0..1
A_Medication
Refers to a target Act instance of the
same class_cd and mood_cd which
is replaced by the source Act instance.
class_cd* <= 'SBADM'
mood_cd CS CNE [1..1] <= EhrMedicationMood
id: II [1..1]
cd: CD CWE [1..1] <= EhrMedicinalProdCode
activity_time: IVL<TS> [1..1]
status_cd: CS CNE [1..1] <= EhrMedicationState
availability_time: TS [1..1]
0..3
AR_Supply
A medication statement represents an an entry in the record that
indicates that one or the following has occured. The clinician has
recommended, prescribed, dispensed or administered an item of
medication or an appliance.
Note that this his is an entry in the record not an actual prescription.
When electronic prescribing is used a copy of the prescription
message may also be forwarded as an instance of attached data.
A_Dosage
AR_Dosage
type_cd CS CNE [1..1] 'COMP'
0..1
class_cd* <= 'SBADM'
mood_cd CS CNE [1..1] <= EhrDosageMood
txt: ED [1..1]
P_Health_care_agent
type_cd*: <= AUT
time: TS
0..*
P_Appointed_health_care_agent0..*
0..*
Choice_Supply
A_Supply_discontinue
A_Ref_medication
AR_Cancels_authorisation
type_cd CS CNE [1..1] 'RVSN'
class_cd* <= 'SBADM'
id: II [1..1]
0..1
AR_Previous_authorisation
type_cd CS CNE [1..1] 'SUCC'
type_cd CS CNE [1..1] 'PRD'
E_Agent_choice
E_Care_provider
(EHPO_CM_MT32000)
class_cd* <= PSN
determiner_cd*: <= INSTANCE
0..1
A_Supply_authorise
class_cd* <= 'SPLY'
0..1 mood_cd CS CNE [1..1] 'INT'
id: II [0..1]
qty: PQ [1..1]
repeat_nbr: INT [0..1] '1'
effective_time: IVL<TS> [0..1]
cd: CS CNE [1..1] <= EhrSupplyType
status_cd: CS CNE [1..1] <= EhrSupplyState
availability_time: TS [1..1]
type_cd*: <= RESPROV
time: TS
0..*
1..1
CMET: (MANU)
0..*
R_Medicinal_prod
R_Provider
class_cd* <= ROL
0..*
AR_Reason
type_cd* <= RSON
0..*
A_Appointment
0..*
class_cd* <= ROL
P_Supply_product
P_Refered_to_provider
type_cd*: <= RESPROV
time: TS
0..*
0..*
R_Health_care_agent
type_cd [1..1] 'COMP'
class_cd* <= 'SPLY'
mood_cd CS CNE [1..1] 'ORD'
id: II [0..1]
cd: CS CWE [1..1] <=EhrDiscontinueReason
effective_time: IVL<TS> [0..1]
status_cd: CS CNE [1..1] <= EhrSupplyState
availability_time: TS [1..1]
0..*
A_Procedure
Indicates a change in relationship between the
patient and a referenced role. Examples include
registration of a patient with a specified GP.
A_Registration
0..1
type_cd* <= ?
class_cd* <= ACT
mood_cd*: <= PRP
AR_Plan_acts
id: II [1..1]
type_cd* <= ?
cd: CD CWE [1..1] <= VmrPlanCode
0..*
0..*
txt: ED [0..1]
status_cd: CS CNE [1..1] <= VmrPlanState
effective_time: TS [0..1]
activity_time: IVL<TS> [0..1]
availability_time: TS [1..1]
Identifies the target of a request.
E.g. the person or department to whom
the patient was referred.
P_Requested_from
class_cd* <= OBS
mood_cd*: <= EVN
id: II [1..1]
cd: CD CWE [1..1] <= VmrObservationCode
txt: ED [0..1]
status_cd: CS CNE [1..1] <= VmrObservationState
effective_time: TS [0..1]
activity_time: IVL<TS> [0..1]
availability_time: TS [1..1]
value: ANY [0..1]
A_Assessment
R_Subject
class_cd* <= 'PAT'
cd CS CWE <= EhrPersonalRels
0..1
1..*
A_Choice
A_Observation
0..*
R_Specimen
A_Request
A request statement represents an entry in
the record that inidicates that a particular
service has been requested. The actual
request may also be present in the record
in the form of a request message within
class_cd* <= 'ROL'
id II [1..1]
0
type_cd* <= COMP 0..*
class_cd* <= 'ENT'
determiner_cd CS CNE [1..1] <= KIND, INST
desc: ST [0..1]
class_cd* <= 'OBS'
mood_cd: CS CNE [1..1] 'EVN'
id: II [1..1]
txt: ED [1..1]
status_cd: CS CNE [1..1] <= EhrActState
availability_time: TS [1..1]
type_cd CS CNE [1..1] 'ORG'
0
AR_Parts
class_cd* <= PSN
determiner_cd*: <= INSTANCE
A_Narrative
A_Attached_data
R_Role_ref
0..*
1..1
E_Patient
P_Specimen
A_Plan
class_cd* <= 'OBS'
mood_cd CS CNE [1..1] 'EVN'
cd CD CWE [1..1] <=EhrAttachmentCode
effective_time IVL<TS> [0..1]
id II [0..1]
value ED [1..1]
0..1
P_Attachment_origin
type_cd*: <= PATSBJ
0..*
E_Subject_person
A plan statement represents an intention or planned action
such as a recall for a particular intervention.
class_cd* <= CTXT
mood_cd*: <= EVN
level_cd: <= CMP
P_Patient
class_cd* <= ROL
Context
Description
A_Collection
0..*
1..*
class_cd* <= 'OBS'
mood_cd: CS CNE [1..1] 'EVN'
id: II [1..1]
0..* activity_time: IVL<TS> [0..1]
cd: CD CWE [1..1] <=EhrObservationCode
effective_time: TS [0..1]
txt: ED [0..1]
value: ANY [0..1]
priority_cd CS CNE [0..1] <=EhrPriority
interpretation_cd CS CNE [0..1] <=EhrInterpret
status_cd: CS CNE [1..1] <= EhrActState
availability_time: TS [1..1]
0..2
Most elements in the GP record will be represented using
observation statements. These will include observations
representing theraputic interventions other than medication.
The observation statement supports coded representation
of clinical information with accompanying text. It includes an
optional quantitative measurement.
(PORX_RM123456)
0..1
R_Patient
Choice_Statement
A_Compound
R_Role_ref
DSS VMR
A single structured statement
which forms part of a composition
within a patient record.
Context
Identifies agents (other than the author or target of a request)
who are referred to by these statements.
E.g. a person who performed or assisted an action,
a person who provided information or a device used in
making an observation.
Notes
The author is recorded at the composition level.
The target of a referral is covered by P_requested_from.
0..*
class_cd* <= ENC
mood_cd*: <= INT+ORD+APT
id: II [1..1]
cd: CD CWE [1..1] <= VmrApptCode
AR_Reason
txt: ED [0..1]
status_cd: CS CNE [1..1] <= VmrApptState type_cd* <= RSON
effective_time: TS [0..1]
0..*
0..*
activity_time: IVL<TS> [0..1]
availability_time: TS [1..1]
A_Education
class_cd* <= ACT
AR_Attached_data*
mood_cd*: <= INT+ORD+EVN
type_cd*: <= APND
id: II [1..1]
cd: CD CWE [1..1] <= VmrEducationCode
1..*
txt: ED [0..1]
status_cd: CS CNE [1..1] <= VmrEducationState
effective_time: TS [0..1]
activity_time: IVL<TS> [0..1]
availability_time: TS [1..1]
A_Educational_data
class_cd* <= ACT
mood_cd*: <= EVN
E_Decision_support_system
class_cd* <= DEV
determiner_cd*: <= INSTANCE
P_Performer
R_Role_ref
0
type_cd: CS CNE [1..1] 'PRF'
class_cd* <= 'ROL'
id II [1..1]
0
0..1
A_Medication
class_cd* <= SBADM
mood_cd*: <= VmrMedicationMood
id: II [1..1]
cd: CD CWE [1..1] <= VmrMedicinalProdCode
status_cd: CS CNE [1..1] <= VmrMedicationState
activity_time: IVL<TS> [1..1]
availability_time: TS [1..1]
A_Aggregate
A_Supply_order
AR_Authorised_by
A_Ref_medication
type_cd CS CNE [1..1] 'FFIL'
class_cd* <= 'SBADM'
id: II [1..1]
AR_Fulfills
type_cd CS CNE [1..1] 'FFIL'
class_cd* <= 'SPLY'
mood_cd CS CNE [1..1] 'ORD'
id: II [0..1]
txt: ED [0..1]
qty: PQ [1..1]
cd: CS CNE [1..1] <= EhrSupplyType
status_cd: CS CNE [1..1] <= EhrSupplyState
0..1 availability_time: TS [1..1]
A_Supply
class_cd* <= 'SPLY'
mood_cd CS CNE [1..1] 'EVN'
0..1 id: II [0..1]
qty: PQ [1..1]
activity_time: IVL<TS> [0..1]
cd: CS CNE [1..1] <= EhrSupplyType
status_cd: CS CNE [1..1] <= EhrSupplyState
availability_time: TS [1..1]
class_cd* <= 'CTXT'
mood_cd: CS CNE [1..1] 'EVN'
level_cd: CV CNE [1..1] <= EhrCompoundLevel
cd: CD CNE [1..1] <=EhrCompoundCode
id: II [1..1]
activity_time: IVL<TS> [1..1]
status_cd: CS CNE [1..1] <=EhrActState
availability_time: TS [1..1]
AR_Encounter
type_cd*: <= OUTC
A_Health_care_intervention
class_cd* <= ACT
mood_cd* <= INT+ORD+EVN
id: II [1..1]
cd: CD CWE [1..1] <= VmrInterventionCode
txt: ED [0..1]
status_cd: CS CNE [1..1] <= VmrInterventionState
effective_time: TS [0..1]
activity_time: IVL<TS> [0..1]
availability_time: TS [1..1]
0..*
0..*
A_Encounter
class_cd* <= ENC
mood_cd*: <= EVN
AR_Reason_for_encounter
type_cd* <= RSON
0..*
0..*
Latest HL7 work
• Reformulating same approach but based on
other TC’s existing messages rather than
G2GP (although this was already occurring)
• Agreement to release as DSTU - draft
standards for trial use rather than to ballot
• But: vMR more than just the model
• Terminology mediation, QoS standards
• Where is the EHR framework in HL7? “rim
light”
• Where is the boundary between model and
terminology?
©2003 Sowerby Centre for Health Informatics at Newcastle
Wider application
• Problems with DSS and vMR are a
microcosm of any (machine) agent to agent
communication – this is just one early
example
• More exacting requirements than most of HL7
contributors appear used to:
Document, human centric view of records
vs. machine to machine, no human interaction
where machines may be in different cultures
©2003 Sowerby Centre for Health Informatics at Newcastle