Skip to content
This repository has been archived by the owner on Jan 9, 2023. It is now read-only.

Investigating the implementation of HL7 #151

Open
3 tasks
matteovivona opened this issue Sep 3, 2019 · 7 comments · May be fixed by vaibhavgupta3110/hospitalrun-server#36 or vaibhavgupta3110/hospitalrun-server#37
Open
3 tasks

Comments

@matteovivona
Copy link
Contributor

matteovivona commented Sep 3, 2019

💬 Questions and Help

We need to understand how to implement HL7 standard in our APIs.

  • HL7 v2 (messages)
  • HL7 v3 CDA (XML) Releases: R1, R2
  • HL7 v4 FHIR (JSON + REST) Releases: R1, R2, R3 & R4
@fox1t
Copy link
Member

fox1t commented Sep 6, 2019

@bazuzu666 let's write down the motivations. It have to be clear for newcomers why we need to support these standards.

@nclBaz
Copy link
Contributor

nclBaz commented Sep 13, 2019

HL7 = Health Level 7 (seven because it corresponds to level 7 of ISO-OSI model)
It is the international standard for clinical data interchange, created to move information about patient data and to standardise the interoperation between various hospital wards and systems.

HL7 versions

  1. v1 was only used for a proof of concept implementation and served to define the content and structure of the standard.

  2. v2 messages are encoded and composed by segments, segments are composed by fields. Each field starts with a pipe symbol and it has a fixed position but some may be optional and some may repeat. Each field has a data type and if it is empty, the pipe maintains its position.

    Examples of segments below:

    • MSH (Message Header)
    • EVN (Event Description)
    • PID (Patient Identification)
    • PV1 (Patient Visit Information)
    • AL1 (Patient Allergy Information)

image

  1. v3 messages are encoded in XML composed by a Header, containing information about the document itself and providing info on authentication, patient and so on, and by a Body, which contains the clinical report and can be either an unstructured blob or a structured markup. The body is composed by section elements each containing narrative blocks (human readable, the content to be rendered) and any number of CDA entries (structured computer-processable components)

    Es:

<ClinicalDocument>
  ... CDA Header ...
  <structuredBody>
    <section>
      <text>...</text>
      <observation>...</observation>
      <substanceAdministration>
        <supply>...</supply>
      </substanceAdministration>
      <observation>
        <externalObservation>...
        </externalObservation>
      </observation>
    </section>
    <section>
        <section>...</section>
    </section>
  </structuredBody>
</ClinicalDocument>
  1. v4 is the newest standard called FHIR (Fast Health Interoperability Resources) and it adheres to RESTful design principles. It supports both XML and JSON. FHIR has many components of CDA, but they are separated into smaller more manageable pieces. When reading data, the biggest difference from CDA is that FHIR provides atomic data access, meaning that instead of needing to transmit and parse huge files, you can use FHIR and make a specific request of a single observation and get that only.

They decided to have v3 non-compatible with v2, so it means that existing 2 interfaces will not be able to communicate with newer v3. Compatibility between v3 & v4 is under investigation. I think they created a new digital divide where apps that need to speak v4 will also need v2 & v3 interfaces to communicate. Moreover each of the three versions comes with multiple revisions.

@PhearZero
Copy link
Contributor

v1-3

Great place for fastify endpoints in #154 .

v4

We will get for free in CouchDB but all other message endpoints must adapt incoming messages to our final specification.

@fox1t
Copy link
Member

fox1t commented Sep 22, 2019

Can we set an ETA for a POC of this integration? We need to expose a specific fastify-plugin.
We need also to decide which version to pick as first. I think we can go with FHIR because it is a super set that uses concept/approaches we already use internally.

@jeremyklein
Copy link

Hi All,

I work in the Healthcare Interoperability/Integration space and have experience with HL7 v2, CDAs, and FHIR. I'm not super familiar with the tech stack in HospitalRun but I would love to learn more.

What are the motivations for implementing HL7 standards? Are there any workflows/integrations you are hoping to support? Integrating Healthcare Enterprises (IHE) describes a number of profiles below which might be helpful to give some context to the integration. https://wiki.ihe.net/index.php/Profiles

I think picking one of these profiles that you think would be useful and then implementing one of the actors would help to limit the scope and add valuable context for the implementation.

I'd be really interested to dig in. Let me know if you want to discuss this further.

@fox1t
Copy link
Member

fox1t commented Dec 7, 2019

Hi Jeremy! Thanks for reaching us. We are going to implement HL7 for sure, starting from FHIR. We already have some internal discussion about this since day one. I would really appreciate if you want to join us. We use our slack as primary communication channel. May I invite you to join it?

@damianesteban
Copy link

I can also help with this. We have implemented both HL7 v2 as well as FHIR integrations at BetterPT.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.