Page tree
Skip to end of metadata
Go to start of metadata

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 NRTitleTo be implemented in OpenNCP
UC1The doctor is authenticated by the portal

Basic functionality already present in OpenNCP portal and in epsos-web.

  1. Check if additional rights need to be assigned to the doctor role for enabling HCER.
UC2The doctor will identify the user. Its covered now from OpenNCP PortalFunctionality 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

  1. Guidelines for the new document type of HCER, start from https://service.projectplace.com/pp/pp.cgi/r844355914
  2. User Interface for filling the HCER document (OpenNCP Portal and epsos-web)
UC5The system will create this new type of cda document and will upload it in the relevant NCP
  1. Method for constructing a valid CDA document (OpenNCP Portal and epsos-web) according to the guidelines formulated in UC4 implementation.
  2. Web service call from the portal to NCP-B client connector for submitting the HCER. Reuse the XDR (eD and consent) implementation.

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:

  1. NCP-B client connector: WSDL extension for HCER.
  2. NCP-B client connector: processing of a web service call with HCER payload from the portal.
  3. Web service call from the NCP-B to NCP-A with HCER payload. Reuse the XDR (eD and consent) implementation.
UC6NCP-A must accept this document and provide info for the result
  1. Add new document class code to XDRServiceImpl: document type detection, call to national connector gateway, audit log method. - DONE but not tested, PT-193 - Getting issue details... STATUS
  2. Extend ncp-a interface: add HCER methods. DONE but not tested, PT-193 - Getting issue details... STATUS
  3. Define exception classes and error codes for HCER processing.
  4. Extend assertion validator and defaultpolicymanager: add HCER class code and any additional permission codes.
UC7Doctor can merge the HCER information into PatientSummary DocumentImplemented as part of UC4 implementation.
UC8The doctor can query for HCER Documents of a patientAssumption: 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

  1. Guidelines for the new document type of HCER
  2. User Interface for filling the HCER document (OpenNCP Portal)
  3. Method for constructing a valid CDA document (OpenNCP Portal)
  4. Method for accepting HCER documents (NCP-A, national connector part)
  5. 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

  1. 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.

6 Comments

  1. IMHO in the exemple, the codeSystemName for 

    2.16.840.1.113883.2.9.6.2.7

    should be "ISCO" and not 

    epSOSHealthcareProfessionalRoles
    epSOSHealthcareProfessionalRoles is the name of the valueSet. 
  2. Your IMHO is very right, Eric. Thank you for noting this, I have now updated the example.

  3. Pls Giorgio Cangioli assist us which section of patient summary have we to use in HCER and fill in

  4. While building the form for medication summary, we have to lookup to the snomed CT and we can't filter only the epsosCodeProb. Have you any idea   Konstantin Hyppönen? These values are taken from the extracted LTR xml files based on EpsosRepository SNOMEDCT.xml file

    1. Can you fetch the values directly from the LTR database? The OID for this value set seems to be 1.3.6.1.4.1.12559.11.10.1.3.1.42.23.

      1. I will check it and perhaps make a change in tsamexport tool in order to have this info also. When the TsamExporter tool has been created one of the requirements was to not directly query the database from any application, but create an app that will fetch data from LTR and write to DB.