1 Ø. Nytrø/I. D. Sørby, IDI, NTNU TDT4210 Lecture Sept. 14th 2005: Part 2: Electronic Patient Records – archives and history

1

Ø. Nytrø/I. D. Sørby, IDI, NTNU

TDT4210 Lecture Sept. 14th 2005:

Part 2: Electronic Patient Records – archives and history

2

The Patient Record: (Norw.: Pasientjournalen)• Eng.:

– EPR: Electronic patient record– EHR: Electronic health record– CPR: Computerized patient record– CMR: Computerized medical record– EMR: Electronic medical record

• The record is:– An account of a patient’s health and disease after he or she has sought

medical help– A legal report of medical actions– A (historic) source of information that is shared among care providers– A working tool supporting patient care – A tool for classification

T. Nystadnes, KITH. Translated/adjusted for TDT4210 by Ø. Nytrø and I. D. Sørby

3


The patient record (cont.):

• Physician’s record, nursing record, dentists record... • Every care provider is obliged to keep a record• The Norwegian Record (”Norgesjournalen”, R. Piene)

– Hierarchic, structured in folders

• Electronic:– First for GPs

– Not paper based

– Scanned paper (!)

– Functionality: Cronological, not contents based

4

Patient record contents:

• Observations• Statements• Test- and laboratory answers• Pictures• Diagnoses• Family information• Assessment• Information about medications• Documents: Reports, sick leaves, prescriptions• Free text notes• Codes: Diagnoses (ICPC, ICD10, SNOMED etc.)


5

Important aspects of the EPR:• Important to distinguish between patient record contents, system,

and user interface (Contents ≠ System ≠ Interface)• Record contents is used differently by health care personnel in various

roles and situations• Possible to utilize an electronic medium such that:

– It is possible to navigate and search in the information – The information can be filtered– The information can be adapted to each individual user (physician, nurse, patient) and

situation

• ”Decision support” used to be ”hot”, but is now merely seen as part of the solutions

• Access control vs. patients’ rights and confidentiality • Patient record contents also used in research activities• Sharing of information between different health care services• Record and record system architecture


6

EPR standardizationFrom structured components to archetypes

Torbjørn Nystadnes, KITH,

Adjusted/translated 2005 by I. D. Sørby

7

Contents

• What is an electronic patient record?• Short ”historic” overview• The main principles in a generic EPR architecture• Two level modeling, use of templates/archetypes

8

Dagbladet 2. Juni 1998:

9

What is an electronic patient record:

• Administrative and medical patient data electronically stored in a consistent way. A computer-based patient record may contain characters, signals, images, and sounds – Normally, only one record for each patient within one health care

service should exist, even if the patient receives help from several categories of care providers

– Different health care services cannot use shared patient records

– The patient’s consent or other legal justification is needed to give access to or to hand out record or record information

10

EPR standardization work

CEN/TC251 - WG1(European Committee for Standardization, Technical Committee for health informatics,

work group 1, www.centc251.org)• 1995: ENV-12265 EHCRA - Electronic healthcare record architecture

– Basic mechanisms to describe data contents and structure– EPR consists of components in a structure

• 1999: ENV13606:Electronic Healthcare Record Communication:– Extended Architecture - generic record architecture– Domain Term List – terms used for headlines for groups of record information– Distribution Rules – access control– Messages for Exchange of Record Information

• 2002: Task Force EHRcom – revision of ENV13606

ISO/TC215 - WG1 http://secure.cihi.ca/cihiweb/dispPage.jsp?cw_page=infostand_ihisd_isowg1_e

• International standards for health informatics• Technical specification: "Requirements for an Electronic Health Record Reference

Architecture”• Co-operation with CEN/TC251

11

CEN/TC251 – WG1

12

Health Level 7 (www.hl7.org)

– An American National Standards Institute (ANSI) approved Standards Developing Organization (SDO).

– A not-for-profit volunteer organization – Its members-- providers, vendors, payers, consultants, government

groups and others who have an interest in the development and advancement of clinical and administrative standards for healthcare—develop the standards

– Health Level Seven’s domain is clinical and administrative data

– HL7 v3 RIM (Reference Information Model)• RIM is a large pictorial representation of the clinical data (domains) and identifies

the life cycle of events that a message or groups of related messages will carry

– Co-operation between CEN/TC251, ISO/TC215, and HL7 in order to harmonize the standardization work

13

openEHR foundationhttp://www.openEHR.org

openEHR aims• promote and publish the formal specification of requirements for

representing and communicating electronic health record information, based on implementation experience, and evolving over time as health care and medical knowledge develop;

• promote and publish EHR information architectures, models and data dictionaries, tested in implementations, which meet these requirements;

• manage the sequential validation of the EHR architectures through comprehensive implementation and clinical evaluation;

• maintain open source "reference" implementations, available under licence, to enhance the pool of available tools to support clinical systems; and

• collaborate with other groups working towards high quality, requirements-based and interoperable health information systems, in related fields of health informatics.

14

CEN Task Force: EHRCom• Revision of ENV 13606 to a adequate European standard (EN) for

communication of EPR

• Is among others based on the following:– ENV13606 – This shall be the basis– Other CEN standards and prestandards– Similar work performed by ISO– The ongoing harmonization process with HL7– The vendors’ experiences with ENV13606 – openEHR– Architecture and domain specific needs are to be separated

• "Archetypes" should be used to describe domain specific needs

– It should be possible to use various communications methods

15

EHRCom

• The work is divided into the following tasks:– Reference Model– Archetype Model– Archetype Generation– Terminology Support– Security Features– Exchange Messages– Liaison with Industry– Documentation and Dissemination

16

Norwegian EPR standard: Architecture, archives and access control

• Initiated by The Ministry of Health and Care Services• Developed by a project task force chaired by KITH:

– The Norwegian Medical Association (Legeforeningen), Norwegian Nurses Association (Sykepleierforbundet), The Norwegian Board of Health, and The National Archival Services of Norway (Riksarkivet) was represented in the working group

– A broad reference group

• Is based on laws and regulations and Norwegian and international standards:

– Noark-4– ENV13606 Electronic Healthcare Record Communication

• Has been on a broad hearing and was finished in June 2001

17

About the standard• The standard should be used for

– Every kind of patient records– In every health care service– The patient records must be able to contain all types of information

• It describes requirements concerning:– Access control– Handling of patients’ rights– One basic, generic record architecture

• But concrete document types etc. is not described

– Mechanisms for handling of code systems etc.– Format for delivery of EPR to depot archive

• Forms a basis for record information exchange between different health care services

18

EPR architecture• EPR consists of components in a structure• Several structures in one record possible, e.g. primarily

organized by:– Process (episode of care etc.)

– Problem

– Traditional topic related document groups

• The structures are primarily hierarchical– Powerful reference mechanisms leads to other opportunities as well

• One component may be located several places…– …but any component has one primary connection to one superior

component (original context)

19

Generic EPR architectureRecord ComponentLink Item

1..*

0..*

1..*

0..*

Character String Item

Real Number ItemInteger Item

Boolean Item Coded Value Item

Point in Time Item

Encapsulated Data Item

Data Item

Fragment

0..*

0..*

0..*

0..*

0..*

1

0..*

1

Composition1..*

0..*

1..*

0..*

Folder

0..*

0..*

0..*

0..*0..*

1..*

0..*

1..*

URL Item

Physical Quantity ItemInstance Identifier Item

EHCR

Root Folder1

1

1

1

"Sak"

"Dokument"

"Fragment"

"Dataelement"

20

The case concept (Norw.: sak)

• The EPR may include the following main case types:– Subject related cases

• E.g.: Document groups according to the recommendations of the Norwegian Board of Health (Helsetilsynet)

• Such cases should normally always stay open

– Problem related cases• Some cases may be related to concrete diagnoses…• Others may be more diffuse

– Process related cases• E.g.: Episode of care, contacts• Shall be able to contain subprocesses

• Every case consists of:– one case head which describes the case, a number of documents and/or

other cases and/or imported documents

21

Cases and documents

Documents

Cases

Episode of care12.-21.06.01

Problem:Diabetes

Test answers - tissue and fluid

22

Documents and fragments• One document represents one independent registration

in the record– Approval as one whole

– E.g.: Record note, referral, discharge report, requisition

• Every document consists of a number fragments– The fragments are approved as part of the document

• Every fragment consists of – one or more data elements

– and/or other fragments

– and possibly one or more headings

23

Documents and fragments

Fragment type: Document headRecipient name, address etc.Patient name, ID number, address

Fragment type: Issued byName of health personnel, role etcHealth care service name, address etc.

Fragment type: Problem descriptionProblem codeProblem description

Fragment type: Desired processCode for treatment or investigation Process codeProcess description

Type of document: Referral

24

Other structure elements• Possibility of links between components in EPR• Links are associated with a link type, e.g.

– <...> is caused by <...>• (the hepatic injury is caused by drug)

– <...> indicates <...> (Norw.: <…> er holdepunktet for <…>)• (the test result indicates an infectious disease)

• Links to components of other patients’ EPR can be created

• Connections to components of the EPR about the same patient at a different health care service can be made

25

Templates for cases, documents, etc.• This is a basic standard which mainly describes how record

contents is to be handled, not the information itself• Document templates are needed in order to be able to use the

standard in particular health care services• A complete (?) set of such templates are developed for the

maternal, child and school health services (Norw.: helsestasjons- og skolehelsetjenesten)

• Templates for medical treatment and some other minor areas are developed

• Templates for other parts of the health care service is under development

26

Two-level modeling: Use of archetypes

Fragment

Instances of Fragment will be either a Headed Section or a Compound, dependent of which kind of archetype it is based upon

Folder ArchetypeFolder OCC1

0..*

1

0..*

Folder Archetype Content0..*

1

0..*

1 0..1

0..*

0..1

0..*

Folder Content Element

1

0..*

1

0..*

0..1

0..*

0..1

0..*

0..1

0..1

0..1

0..1

is constraind by

Composition Archetype0..1

0..*

0..1

0..*

Composition OCC

1

0..1

1

0..1

0..*

0..1

0..*

0..1

0..*

1

0..*

1

Composition Archetype Content0..*

10..*

1

Composition Content Element

1..*1

1..*1

is constraind by

Headed Section Archetype

Fragment Archetype

0..*

1

0..*

1

Compound Archetype

0..*

0..1

0..*

0..1 0..1

0..1

0..1

0..1

10..* 10..*

Headed Section Archetype Content

1

1..*

1

1..*

0..*

0..1

0..*

0..1

Compound Archetype Content

1

1..*

1

1..*

0..*

0..1

0..*

0..1

Fragment Content Element

0..1

0..*

0..1

0..*

1..*

1

1..*

1

0..10..1

Data Item Archetype

0..*

0..1

0..*

0..10..*

0..1

0..*

0..1

Data Item

0..1

1

0..1

1

10..1 10..1

is constraind by

is constraind by

27

Template development

Information model

Original "document"

Personetternavn : ST(50)mellomnavn : ST(50)fornavn : ST(50)meldingsintern person ID : ST(10)

Arbeidsforholdyrkeskode : CSprimært arbeidsforhold : BLyrkesbetegnelse : ST(70)virksomhet : INT(10)

0..*

1

0..*

1

Rolle i forhold til pasient

rolle i forhold til pasient : CSreferanse til pasient : ST(10)

Virksomhetavsender : BLbetegnelse : ST(70)organisasjonsnummer : ST(9)type helsevirksomhet : CSmeldingsintern virksomhet ID : ST(10)

0..*virksomhet

10..* 1virksomhet

Pasientfødselsdato : TSfødselsnummer : ST(11)D-nummer : BLannen ID : ST(30)type annen ID : ST(70)bydel : CSkommune : CSnasjonalitet : CStrygdekontor : ST(50)

1

referanse til pasient1

1

1referanse til pasient

Ansvarlig helsepersonellhelsepersonellnummer : ST(9)kategori helsepersonell : CS

1

0..1

1

0..1

EPJ-melding

1..*

1

1..*

1

1..*

1

1..*

1

1

1

1

1

EHCR system

"EHCR template"

XML-Schema

XML -document

with clinical

information

XML document

EHCR message

Envelope

Documentation

Template "editor"

XML document that includes "mapping" to

the HL7 rim

28

Medication templates

Fixed Time Dose

time of first dose : TSinterval : INT

Unscheduled Dose

max dose pr unit of time : REALmax dose unit of time : CSminimum dose interval : REALminimum dose interval unit of time : CSrepeat interval : INT

Distributed medical product

number of doses : INT

Administered by Patient

1..*1..*Administered by HCA

administration status : CS

Medicinal product

medical product category : CSmedical product ID : INTname of product : ST(100)ATC-numbert : CSform : CS

Dose administration

single dose qyantity : REALsingle dose unit : CSadministration start : TSadministration end : TSadministrered by : R-T

Infusion Speed

infusion volum : REALunit of time : CS

Medication administration document

1..*

1

1..*

1

Dosage Rule

basis for dos calculation : CSnote : STDose

single dose quanttity : REALsingle dose unit : CS 0..11 0..11

Ingredient

number of units : REALunit of medical product : CS

Prescription Termination

time of cancelation : TSnote : ST

MedicationOverview Folder

0..*

1

0..*

1

Dosage

administration instruction : ST(100)start : TSend : TS

0..1

1

0..1

1

1..*

1

1..*

1

Prescribed Medical Product Composition

1

1..*

1

1..*

Prescription document

0..*

1

0..*

1

0..*

1

0..*

1

Prescribed medicinal product

quantity : ST(50)

Single prescription

administration by : CSmethod of administration : CSprotocol based administration : BLreiteration : INT(2) = 0reimbusment time : TSnote : ST

0..*

1

0..*

1

0..1 10..1 10..*1 0..*1

0..1

1

0..1

1referes to

0..n

1

distributed dose0..n 1

Folder Composition Headed Section

data item : data type

administrered dose0..n 1

29

Access control

• Principle:– A decision to carry out a concrete procedure with a legal objective has to be

made before access to a patient record can be given

• Decided action/process is used to state the aim of the access and to delimit what health information that can be accessed

• Roles describe the health care personnel’s rights according to treatments etc.

• Roles are connected to organizational units• Some types of actions/procedures may only be effectuated if a

former action which opens for this has been effectuated

30

Access consent (Norw: Samtykke til innsyn)• The patient has the right to deny health care personnel access

to his/her record (but there are exceptions)

– It should be possible to registrer the patient’s consent claim in the record • The claims might be connected to parts of the record, e.g. one case

• The claims mighht be directed towards specific persons

• Some selected actions/treatments can be excepted from the consent claim

– It should be possible to state in the record if others than the patient can give access consent

– The patient’s access consent can be limited to a specific action or a specific service provision

31

Registered in

Information

Service provider: Kari Ås, surgeonDept. of surgery

Leads to need of

EPR: Per Spellman’s record

Appear as

Org. unit: Dept. of surgery

Might bring forward

Document templates 1 year follow-up

Based upon

Performs

Decided procedure: 1 year follow-up

Consent claim

Service provision: 1 year follow-up

Procedure deskr. etc. Follow-up programme

Per Spellmann,patient

Has

Role: Physician, Dept. of surgery

at

HasAppear as

Performs

Has connected

Based upon

Give access to

Role template: Physician

Procedure template: 1 year follow-up

Ola Normann

Contains

Service provider: Ola Normann. physician, Dept. of surgery

Has decidedKari Ås

Principles for access control

32

Informasjon

Tjenesteyter: Kari Ås, kirurgKirurgisk avdeling

Medfører behovfor

EPJ: Per Spellmans journal

Opptrer som

Org. enhet: Kirurgisk avd.

Kan komme med

Dokumentmaler 1 år oppfølging

Basert påUtfører

Besluttet tiltak: 1 år oppfølging

Samtykkekrav

Tjenesteytelse: 1 år oppfølging

Prosedyrebeskr. etc. Oppfølgingsprogram

Per Spellmann,pasient

Har

Rolle: lege, Kirurgisk avdeling

ved

Har

Registrert i

Opptrer som

Utfører

Har tilknyttet

Basert på

Gir tilgang til

Rollemal: Lege

Tiltaksmal: 1 år oppfølging

Ola Normann

Inneholder

Tjenesteyter: Ola Normann. lege, Kirurgisk avdeling

Har besluttetKari Ås

Prinsipper for tilgangsstyring

33

National strategy for electronic patient records, pre-project (S@mspill 2007)

• One of the efforts in the S@mspill report and in “Superior ICT strategy for the regional health care services“

• The pre-project shall propose visions and directions for the development of EPRs in Norway, and suggest a plan for further actions

• The project is co-ordinated with other EPR related actions under National ICT

• Report: http://www.shdir.no/vp/multimedia/archive/00001/10-_EPJ-strategi_pros_1529a.doc

• National architecture strategy: //www.hemit.no/upload/2221/Forprosjektrapport_v1_1.pdf • Nasjonal IKT: http://www.shdir.no/index.db2?id=5258

34

DocuLive demonstration

• DocuLive EPR system is used in several Norwegian Hospitals; e.g. St. Olavs hospital in Trondheim

• www.hemit.no/elaring