CEN Messaging

1
CEN Messaging EHR Standards

• Serkan Kirbas
• SRDC

2
Presentation Outline

• CEN CEN Standards
• ENV 13606-Part4
• prEN 13606-Part1
• Conclusion

3
CEN CEN Standards

• Comité Européen de Normalisation
• CEN's mission is to promote voluntary technical
  harmonization in Europe in conjunction with
  worldwide bodies and its partners in Europe.
• TC251 do the standardization in the field of
  Health Information and Communications Technology

4
CEN CEN Standards (Cont)

• TC251 published ENV 13606 in 1999
• TC251 is working on EN 13606 currently (prEN
  13606)
• These are electronic health record communication
  standards

5
CEN CEN Standards (Cont)

• the basic aim of ENV 13606 is to enable record
  exchange partially or fully between heterogeneous
  systems.

6
CEN CEN Standards (Cont)

• the safe and fully automatic processing is not
  possible!!!
• It is basically for human!

7
Presentation Outline

• CEN CEN Standards
• ENV 13606-Part4
• Introduction
• Use Cases
• prEN 13606-Part1
• Conclusion

8
ENV 13606-Part4

• ENV 13606 has 4 parts
• Part 1 Extended architecture
• Part 2 Domain termlist
• Part 3 Distribution rules
• Part 4 Messages for the exchange of information

9
ENV 13606-Part4 (Cont)

• exchange of electronic healthcare record
  information
• for the provision of clinical care to an
  individual patient.
• from an electronic healthcare record held by one
  health professional to be sent to another health
  professional.

10
ENV 13606-Part4 (Cont)

• There are 3 types of messages in the
  ENV13606-Part4
• request EHCR message
• provide EHCR message
• EHCR notification message

11
ENV 13606-Part4 (Cont)

• request EHCR message
• This type of messages are send when the sender
  needs to retrieve healthcare information from
  the receiver part.
• This type of messages resembles the queries about
  the underlying healthcare information.

12
ENV 13606-Part4 (Cont)

• provide EHCR message This type of messages are
  send when the sender needs to provide healthcare
  information to the receiver part. This type of
  messages resembles the answers to the queries
  about the underlying healthcare information. But
  it is not necessary for a request EHCR message to
  precede a provide EHCR message. (Look at the use
  cases)

13
ENV 13606-Part4 (Cont)

• EHCR notification message This type of messages
  is usually used to notify the receiver about the
  acceptance, refusal of the request or the
  received provide message.

14
ENV 13606-Part4 (Cont)

• Use Cases
• Use Case 1
• A patient consults or registers with a new GP
  after moving to another area.
• A patient chooses to change the specialist or
  clinic that they attend.

15
ENV 13606-Part4 (Cont)
16
ENV 13606-Part4 (Cont)

• Use Cases
• Use Case 2
• A GP refers a patient to a specialist.
• A specialist involves a therapist in a particular
  aspect of a patient's care.

17
ENV 13606-Part4 (Cont)
18
ENV 13606-Part4 (Cont)

• Use Cases
• Use Case 3
• GP and diabetic specialist providing care to a
  diabetic patient.
• GP and Midwife and/or Obstetrician providing
  antenatal care.

19
(No Transcript)
20
Presentation Outline

• CEN CEN Standards
• ENV 13606-Part4
• prEN 13606-Part1
• Conclusion

21
prEN 13606-Part1

• presents a generic information model for
  communicating the electronic health record of any
  one patient
• refinement of ENV13606 Part 1.
• inherently hierarchical

22
prEN 13606-Part1

• Reference Model is needed because 85-95 of the
  healthcare documents are paper based.
• So there is lack of usable and re-usable
  electronic data.

23
prEN 13606-Part1

• UML diagram of Reference Model
• The root class of the Reference Model is
  EHR_EXTRACT

24
prEN 13606-Part1

• The order of the class hierarchy from top to
  bottom is (Parenthesis means optional)
• Extract -gt Folder -gt Composition gt (Section) -gt
  Entry -gt (Cluster) -gt Element

25
prEN 13606-Part1
26
prEN 13606-Part1

• Extract It is the root class to hold the
  clinical information about a single patient.
• Folder There is a strong analogy with the real
  meaning of the word folder. This class is used
  to hold the different information components
  related to the patient. So this can be thought as
  a directory.

27
prEN 13606-Part1

• Composition It corresponds to an HL7 CDA
  document. This class fulfils two roles within the
  EHR_EXTRACT.
• Firstly it is the main container of EHR data
  within the Extract itself
• The COMPOSITION is intended to represent the set
  of EHR data that would be committed to a
  patient's record by one party at a particular
  moment in time. In many clinical systems, the
  COMPOSITION will correspond to the set of entries
  comprising a single clinical care session, or a
  clinical document such as a test result,
  discharge summary of a letter.

28
prEN 13606-Part1

• Section The record entries relating to a single
  clinical session are usually grouped under
  headings that represent phases or sub-topics
  within the encounter, or assist with layout and
  navigation. It is usually used for a clinical
  workflow during a care session.

29
prEN 13606-Part1

• Entry This class represents the information
  acquired and recorded for a single observation or
  observation-set battery), a single clinical
  statement such as a portion of the patient's
  history or an inference or assertion, or a single
  action that might be intended or has actually
  been performed.
• Entry can include HL7 mood code and/or Component
  Annotations (This standard part 2, term list)

30
prEN 13606-Part1

• The ITEM, CLUSTER and ELEMENT combination
  supports a wide range of simple and complex data
  structures to be used to represent the actual
  data for one observation or battery

31
prEN 13606-Part1

• The Element class represents the leaf node within
  the EHR hierarchy.
• Each instance of this class will have a single
  Data Value (A ratio, an interval or a
  co-ordinated term).

32
prEN 13606-Part1
33
Presentation Outline

• CEN CEN Standards
• ENV 13606-Part4
• prEN 13606-Part1
• Conclusion

34
Conclusion

• Neither ENV13606 nor prEN13606 provide a direct
  classification of the messages and the clinical
  document components.
• these standards indirectly support the
  classification by enabling the attributes to be
  values from the coded classification standards.

35
Conclusion

• So the safe automatic processing is not
  possible!!!
• this is usually the case for the messaging
  standards. Since the content of the messages
  should be designed flexible enough to be able to
  hold all kind of healthcare information,
• the automatic interpretation of the messages is
  sacrificed.

36
Thanks !