iEHR.eu IHIC 2013 Presentation

Extensions to HL7 V3 Standards Designed for
the First Polish Nationwide Implementation:
Reasoning and Modelling
Roman Radomski, Sebastian Bojanowski
iEHR.eu, Warsaw, Poland
October 29, 2013

2014-03-06

1

14th International HL7 Interoperability Conference

eHealth in Poland
• The main project of Polish eHealth aims at building the central
information system supporting common exchange of
electronic medical documents.
• Three types of documents: eReferral, ePrescription and
eOrder of Supply are to be uploaded to the central repository
to be accessed by the potential service providers.
• Other documents are to be stored locally, but their metadata
will be sent to the same central system and published in the
form of document registry.


HL7 v3 Implementation Guide
• HL7 CDA and V3 have been chosen as the standards for
documents and messages to be exchanged with the central
system.
• Due to the official project timeline, the large scale
amendments of the current regulations and printed
document forms were excluded.
• Draft CDA implementation guide for all 3 document types has
been developed by iEHR.eu and distributed by the official
government agency CSIOZ for review.
• The message template for other documents metadata
exchange has been designed on the basis of the HL7 Medical
Records R-MIM.


Local extensions
• Most of the clinical concepts represented in the documents
have been successfully mapped to the CDA, although 8 local
extensions had to be defined.
• One extension has been defined for the HL7 v3 message being
sent to the central repository.


Entitlement document
• The clinical document may contain information on non-clinical
document allowing patient’s entitlement to the particular
medical service coverage plan.
• The information consists of the document type and the
document number (identifier).
– The special entitlement resulting from the document is not explicit in
the document.
– The entitlement is subject to the operational context (planned service,
local conditions, region) and may vary in time, but it does not change
the document information.


Entitlement document

Constraint: Document id and code

id.root = OID nodes for entitlement documents identifiers
code.codeSystem = OID node for entitlement documents types value set


Special entitlement
• There are special entitlements (e.g to the drug refund
coverage plans) that should be indicated in the prescription
document.
– The value sets of those coverage plans are regulated by law.


Special entitlement

Constraint: CoveragePlan.code

code.code = "PUBLICPOL"
code.codeSystem = "2.16.840.1.113883.11.19350” (ActInsurancePolicyCode)
code.qualifier.name.code = "RLEKUD" (drug refund based on special entitlement)
code.qualifier.name.codeSystem = OID node for coverage plans value set
code.qualifier.value.codeSystem = OID node for special entitlements value set


Coverage eligibility confirmation
• There is a procedure for online confirmation of patient
eligibility to the national health insurance.
• The confirmation has a form of a string and needs to be
included in the clinical document issued when refunded
service is performed.
– The confimation string is not an identifier of an insurance policy or any
other entitlement document.


Coverage eligibility confirmation

Constraint: CoverageEligibilityConfirmation id and code

id.root= OID node for coverage eligibility confirmation identifiers
code.code = "ELG " (eligible)
code.codeSystem = "2.16.840.1.113883.11.17488"
(ActCoverageEligibilityConfirmationCode)


Multiple birth indicator and order number
• Newborns are identified by their mother identifier and the
birth date.
• Multiple birth newborns are identified by their mother
identifier, the birth date and the birth order number.
– All those identifying data needs to be included in every clinical
document until the proper national identifier is given - usually it takes
couple of weeks.


Multiple birth indicator and order number


Close person
• There are specific document forms in Poland which require
providing given names of patient’s parents as an additional
patient identifying information.
– This is not an information about patient’s guardian.
– This is not a participation in the act of clinical document or in any act
being documented.
– The document does not contain any other information about patient’s
parents.


Close person

Constraint: PersonalRelationship.code

code.codeSystem = "2.16.840.1.113883.11.19563" (PersonalRelationshipRoleType)


Physician speciality
• Prescriptions for specific drugs and medical equipment supply
require to be issued by physicians of particular specialities.
• Common practice is to include all medical specialities of
document authenticator in every clinical document issued.
– The document content and context may not be relevant to the
physician’s medical speciality.
– The value set of medical specialities is regulated by law.


Physician speciality

Constraint: Qualification.code

code.codeSystem = OID node for physician specialities value set


Drug payment level
• Drug may be refunded on various levels according to the
public insurance/coverage plan.
• The same drug may be refunded on different levels depending
on clinical context.
– Physician is expected to determine the patient’s payment level for the
drug being prescribed.
– The value set of drug payment levels is regulated by law.
– The national health fund conducts continous fraud detection to ensure
proper drug refund processes.


Drug payment level

Constraint: CoveragePlan.code

code.code = "PUBLICPOL"
code.codeSystem = "2.16.840.1.113883.11.19350” (ActInsurancePolicyCode)
code.qualifier.name.code = "POLEKR" (refunded drugs payment levels)
code.qualifier.name.codeSystem = OID node for coverage plans value set
code.qualifier.value.codeSystem = OID node for refunded drugs payment levels value set


Drug substitution
• The default rule is that pharmacist can substitute the
prescribed drug with its equivalent, unless the drug
prescription contains „no substitution” remark.
– The problem of drug substitution is rather sensitive, due to business
competition between pharmaceutical companies and its potential
influence on the medical professionals.


Drug substitution

Constraint: Substitution.code

code.code = "N" (none)
code.codeSystem = "2.16.840.1.113883.11.16621" (ActSubstanceAdminSubstitutionCode)


Supporting Clinical Statement
• The message containing metadata of clinical document being
issued is sent to the central repository.
– This message has to contain information about diagnosis placed in the
context of the document.


Supporting Clinical Statement
Medical Records

Clinical Statement

Constraint: Observation.code

code.codeSystem = OID node for official Polish translation of ICD-10


New Timeline for the Polish eHealth Agenda
• The central system (P1) to be ready by mid 2014
• First production use of P1 at beginning of 2015
• The electronic drug prescription obligatory for all healthcare
providers in 2015 or 2016
• Other documents will be obligatory gradually from 2016


iEHR.eu IHIC 2013 Presentation

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to iEHR.eu IHIC 2013 Presentation

Similar to iEHR.eu IHIC 2013 Presentation (20)

Recently uploaded

Recently uploaded (20)

iEHR.eu IHIC 2013 Presentation