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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a iEHR.eu IHIC 2013 Presentation

Similar a iEHR.eu IHIC 2013 Presentation (20)

Último

Último (20)

iEHR.eu IHIC 2013 Presentation