iehr.eu ihic 2013 presentation

2014-03-06 1

14th International HL7 Interoperability Conference

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

http://iehr.eu/


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 beingsent to the central repository.


Entitlement document

• The clinical document may contain information on non-clinicaldocument allowing patient’s entitlement to the particularmedical 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 changethe document information.


Entitlement document

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

Constraint: Document id and code


Special entitlement

• There are special entitlements (e.g to the drug refundcoverage plans) that should be indicated in the prescriptiondocument.

– The value sets of those coverage plans are regulated by law.


Special entitlement

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 setcode.qualifier.value.codeSystem = OID node for special entitlements value set

Constraint: CoveragePlan.code


Coverage eligibility confirmation

• There is a procedure for online confirmation of patienteligibility to the national health insurance.

• The confirmation has a form of a string and needs to be included in the clinical document issued when refundedservice is performed.

– The confimation string is not an identifier of an insurance policy or anyother entitlement document.


Coverage eligibility confirmation

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

Constraint: CoverageEligibilityConfirmation id and code


Multiple birth indicator and order number

• Newborns are identified by their mother identifier and the birth date.

• Multiple birth newborns are identified by their motheridentifier, the birth date and the birth order number.

– All those identifying data needs to be included in every clinicaldocument until the proper national identifier is given - usually it takescouple 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

code.codeSystem = "2.16.840.1.113883.11.19563" (PersonalRelationshipRoleType)

Constraint: PersonalRelationship.code


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

code.codeSystem = OID node for physician specialities value set

Constraint: Qualification.code


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 dependingon 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 ensureproper drug refund processes.


Drug payment level

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 setcode.qualifier.value.codeSystem = OID node for refunded drugs payment levels value set

Constraint: CoveragePlan.code


Drug substitution

• The default rule is that pharmacist can substitute the prescribed drug with its equivalent, unless the drugprescription contains „no substitution” remark.

– The problem of drug substitution is rather sensitive, due to business competition between pharmaceutical companies and its potentialinfluence on the medical professionals.


Drug substitution

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

Constraint: Substitution.code


Supporting Clinical Statement

• The message containing metadata of clinical document beingissued is sent to the central repository.

– This message has to contain information about diagnosis placed in the context of the document.


Supporting Clinical Statement

Clinical StatementMedical Records

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

Constraint: Observation.code


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 healthcareproviders in 2015 or 2016

• Other documents will be obligatory gradually from 2016

iehr.eu ihic 2013 presentation

Technology