HCER Service for Patient Summary Extension
- Kostas Karkaletsis
- Konstantin Hyppönen
Owned by Kostas Karkaletsis
Problem Statement
The HCER supports the patient summary extension use case In this use case, after a PS is retrieved by country B, country A is informed on the healthcare encounter in country B, so country A is able to update the history of treatment events (according to its own policies).
Only the new information is sent from Country B to Country A, old clinical information is not included in the document.
Users Involved
Physician/Doctor
List Of Features
| Use Case NR | Title | To be implemented in OpenNCP |
|---|---|---|
| UC1 | The doctor is authenticated by the portal | Basic functionality already present in OpenNCP portal and in epsos-web.
|
| UC2 | The doctor will identify the user. Its covered now from OpenNCP Portal | Functionality already present in OpenNCP portal and in epsos-web. XCPD binding. |
| UC3 | The doctor asks to create a HCER document, He also can see the patient summary document (TRCA and consent must be applied) | Assumption: Use case starts by fetching the patient summary. Then a HCER can be created as a modification of the fetched PS. Reuse the eP+eD idea for the user interface in the portal. Extension in a later sprint: If the patient does not have a PS, a HCER can be created from scratch. |
| UC4 | The system will be able to generate a new type of document HCER. The system provides the correct UI to do this |
|
| UC5 | The system will create this new type of cda document and will upload it in the relevant NCP |
The following operations are apparently not required, as in the NCP-B client connector operations and WSDLs are content-agnostic and can handle HCER documents without changes:
|
| UC6 | NCP-A must accept this document and provide info for the result |
|
| UC7 | Doctor can merge the HCER information into PatientSummary Document | Implemented as part of UC4 implementation. |
| UC8 | The doctor can query for HCER Documents of a patient | Assumption: it is the responsibility of the country A to integrate the previously submitted HCER to the patient's PS. Therefore the doctor can query PS for getting HCER information. |
What must it be implemented
- Guidelines for the new document type of HCER
- User Interface for filling the HCER document (OpenNCP Portal)
- Method for constructing a valid CDA document (OpenNCP Portal)
- Method for accepting HCER documents (NCP-A, national connector part)
- Method for merging HCER documents into Patient Summary (NCP-A). This can be decided in NCP-A method that will accept HCER document
The order of implementation
Stage 1: Implement the service for only one section of HCER: make it possible for the physician to report a new diagnosis from Country B to Country A. The diagnosis is reported using the ICD-10 code system and any additional information supported by this document section.
Stage 2: Extend the implementation with other sections.
Questions / Open Issues
- It has to be decided which type of Audit Message will be used for logging this action
CDA-related guidelines
Taken from https://service.projectplace.com/pp/pp.cgi/r844355914
CDA Header
Template id:
<!-- conforms to epSOS HCER requirements -->
<templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.1.4"/>
Document id (an OID generator):
<id root="1.3.6.1.4.1.28284.6.2.4.75" extension="201304291013151234"/>
Code:
<code codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" code="34133-9" displayName="Summarization of Episode Note"/>
Title:
<title>Health Care Encounter Report</title>
Time when the HCER document was generated (current time):
<effectiveTime value="20130429101315+0300"/>
Confidentiality code, value is N.
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25" codeSystemName="HL7:Confidentiality" displayName="normal"/>
Language code, must be taken from portal configuration.
<languageCode code="et-EE"/>
Author is to be filled with portal user's data (the logged in user's and its organization's details). Reuse eD implementation for this.
<author>
<time value="20120519234435+0300"/>
<assignedAuthor classCode="ASSIGNED">
<id root="1.3.6.1.4.1.28284.6.2.4.32"/>
<assignedPerson>
<name>
<given>Patient Summary</given>
<family>Fetcher</family>
</name>
</assignedPerson>
<representedOrganization>
<id root="1.3.6.1.4.1.28284.6.2.4.1" extension="90009016"/>
<name>Eesti E-Tervise SA</name>
<telecom use="WP" value="tel:+3726943900"/>
<telecom use="WP" value="mailto:e-tervis@e-tervis.ee"/>
<addr>
<country>EE</country>
<city>Tallinn</city>
<postalCode>10134</postalCode>
<streetAddressLine>Uus-Tatari 25 / Veerenni 13</streetAddressLine>
<state nullFlavor="NI"/>
</addr>
</representedOrganization>
</assignedAuthor>
</author>
Custodian data, from portal configuration:
<custodian>
<assignedCustodian>
<representedCustodianOrganization>
<id root="1.3.6.1.4.1.28284.6.2.4.1" extension="90009016"/>
<name>Eesti E-Tervise SA</name>
<addr>
<country>EE</country>
<city>Tallinn</city>
<postalCode>10134</postalCode>
<streetAddressLine>Uus-Tatari 25 / Veerenni 13</streetAddressLine>
<state nullFlavor="NI"/>
</addr>
</representedCustodianOrganization>
</assignedCustodian>
</custodian>
Legal authenticator data, from portal configuration:
<legalAuthenticator>
<time value="20120519234435+0300"/>
<signatureCode nullFlavor="NI"/>
<assignedEntity>
<id root="1.3.6.1.4.1.28284.6.2.4.32" assigningAuthorityName="Digilugu"/>
<assignedPerson nullFlavor="NI"/>
<representedOrganization>
<id root="1.3.6.1.4.1.28284.6.2.4.1" extension="90009016"/>
<name>Eesti E-Tervise SA</name>
<telecom use="WP" value="tel:+3726943900"/>
<telecom use="WP" value="mailto:e-tervis@e-tervis.ee"/>
<addr>
<country>EE</country>
<city>Tallinn</city>
<postalCode>10134</postalCode>
<streetAddressLine>Uus-Tatari 25 / Veerenni 13</streetAddressLine>
<state nullFlavor="NI"/>
</addr>
</representedOrganization>
</assignedEntity>
</legalAuthenticator>
The same data as in the author element is stored in the documentationOf section. In addition to that, values of <low> and <high> elements must be editable. Default values as suggested to the user by the UI: current time.
<documentationOf>
<serviceEvent classCode="PCPR">
<effectiveTime>
<low value="20120519234435+0300"/>
<high value="20120619234435+0300"/>
</effectiveTime>
<performer typeCode="PRF">
<functionCode code="222" codeSystem="2.16.840.1.113883.2.9.6.2.7" codeSystemName="ISCO" displayName="Nursing and midwifery professionals"/>
<assignedEntity>
<id root="1.3.6.1.4.1.28284.6.2.4.32"/>
<assignedPerson>
<name>
<given>Patient Summary</given>
<family>Fetcher</family>
</name>
</assignedPerson>
</assignedEntity>
</performer>
</serviceEvent>
</documentationOf>
The relatedDocument tag includes a XFRM reference to the PDF version of the HCER, if it is generated by the portal (optional).
<relatedDocument typeCode="XFRM">
<parentDocument>
<id root="1.3.6.1.4.1.28284.6.2.4.75" extension="201304291013151234"/>
</parentDocument>
</relatedDocument>
Another relatedDocument tag includes an APND reference to the XML version of the patient summary previously fetched by the portal.
<relatedDocument typeCode="APND">
<parentDocument>
<id root="2.16.17.710.820.1000.990.1.1.1" extension="201304290913154321"/>
</parentDocument>
</relatedDocument>
CDA Body (under work)
The CDA body in the first version of the implementation only contains the Active Problems Section (1.3.6.1.4.1.19376.1.5.3.1.3.6) using which the health care professional reports a problem newly discovered in Country B. Below is an example of the body including such a section. Please pay attention to the comments, as there are further UI-related instructions in them.
<component>
<structuredBody>
<component>
<section>
<templateId root="2.16.840.1.113883.10.20.1.11"/>
<templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.6"/>
<code code="11450-4" displayName="Problem list" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
<title>Problem list</title>
<text>
<table border="1">
<tbody>
<tr>
<th>Code</th>
<th>Description</th>
</tr>
<tr ID="problem.1">
<!-- A code selected from the epSOSCodeProb value set. -->
<td>55607006</td>
<!-- A description of the concern, which can be more precise than the ICD-10 value selected from the code system -->
<!-- This is a free text field, default value of which is the ICD-10 code value. The HCP may provide more details using this field -->
<td>Acute angle closure glaucoma</td>
</tr>
<tr ID="problem.2">
<!-- A code selected from the epSOSCodeProb value set. -->
<td>55607006</td>
<!-- A description of the concern, which can be more precise than the ICD-10 value selected from the code system -->
<!-- This is a free text field, default value of which is the ICD-10 code value. The HCP may provide more details using this field -->
<td>Diabetic ketoacidosis</td>
</tr>
</tbody>
</table>
</text>
<entry typeCode="DRIV">
<act classCode="ACT" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.1.27"/>
<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.1"/>
<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.2"/>
<!-- This required element identifies the concern. -->
<!-- Unique identifier for this concern. The identifier is generated by the portal, at least the root must be changeable in the portal configuration -->
<id extension="problem.1" root="2.16.470.1.100.1.1.1000.990.1"/>
<!-- The code is not applicable to a concern act, and so shall be recorded as shown above.-->
<code nullFlavor="NA"/>
<!-- The statusCode associated with any concern must be one part of the above mentioned values.
Note: A concern in the "active" state represents one for which some ongoing clinical activity is expected,
and that no activity is expected in other states. Specific uses of the suspended and aborted states are left to the implementation.-->
<!-- The value is either "active" or "completed", depending on the choice made by the user.
The user has two options: "Clinical activity is expected" (mapped to "active") and "Clinical activity is not expected" (mapped to "completed") -->
<statusCode code="active"/>
<!-- The <effectiveTime> element records the starting and ending times during which the concern was active.-->
<effectiveTime>
<!-- The <low> element shall be present. The value must be editable in the UI. The default value is current time.-->
<low value="20130429101112"/>
<!-- If the user selected "Clinical activity is not expected" in the previous choice, the <high> element (and a corresponding field in the UI) must be present.
Otherwise the element and the field are not present -->
<!-- The value must be editable in the UI. The default value is current time.-->
<high value="20130429101112"/>
</effectiveTime>
<entryRelationship inversionInd="false" typeCode="SUBJ">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.1.28"/>
<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>
<!-- Unique identifier for the observation related to this concern. In the portal, the identifier is an extension of the unique identifier for the concern -->
<id extension="problem.1.obs.1" root="2.16.470.1.100.1.1.1000.990.1"/>
<!-- A code selected by the user from the epSOSCodeProb value set. The code goes also to the narrative block. -->
<code code="55607006" displayName="Problem" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
<text>
<!-- A reference to the narrative block, reference target must be found in one of ID attributes in the narrative block -->
<reference value="#problem.1"/>
</text>
<!-- A clinical document normally records only those condition observation events that have been com-pleted,
not observations that are in any other state. Therefore, the <statusCode> shall always have code='completed'.-->
<statusCode code="completed"/>
<!-- the same contents for the effectiveTime as defined above -->
<effectiveTime>
<low value="20130429101112"/>
<high value="20130429101112"/>
</effectiveTime>
<!-- A code selected by the user from epSOSIllnessesandDisorders (ICD-10). -->
<value code="H40" displayName="Glaucoma" codeSystem="1.3.6.1.4.1.12559.11.10.1.3.1.44.2" codeSystemName="ICD-10" xsi:type="CD"/>
</observation>
</entryRelationship>
</act>
</entry>
<!-- Multiple problems may be reported using the UI. Here is one more example. -->
<entry typeCode="DRIV">
<act classCode="ACT" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.1.27"/>
<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.1"/>
<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.2"/>
<id extension="problem.2" root="2.16.470.1.100.1.1.1000.990.1"/>
<code nullFlavor="NA"/>
<statusCode code="completed"/>
<effectiveTime>
<low value="20130326"/>
</effectiveTime>
<entryRelationship inversionInd="false" typeCode="SUBJ">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.1.28"/>
<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>
<id extension="problem.43.obs.1" root="2.16.470.1.100.1.1.1000.990.1"/>
<code code="55607006" displayName="Problem" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
<text>
<reference value="#problem.2"/>
</text>
<statusCode code="completed"/>
<effectiveTime>
<low value="20130326"/>
</effectiveTime>
<value code="E14" displayName="Unspecified diabetes mellitus" codeSystem="1.3.6.1.4.1.12559.11.10.1.3.1.44.2" codeSystemName="ICD-10" xsi:type="CD"/>
</observation>
</entryRelationship>
</act>
</entry>
</section>
</component>
</structuredBody>
</component>
Specifications for the document sections are in D3.9.1 Appendix B1/B2, PS-related specifications for the sections.