Open matteovivona opened 5 years ago
@bazuzu666 let's write down the motivations. It have to be clear for newcomers why we need to support these standards.
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
v1 was only used for a proof of concept implementation and served to define the content and structure of the standard.
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:
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>
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.
Great place for fastify endpoints in #154 .
We will get for free in CouchDB but all other message endpoints must adapt incoming messages to our final specification.
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.
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.
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?
I can also help with this. We have implemented both HL7 v2 as well as FHIR integrations at BetterPT.
💬 Questions and Help
We need to understand how to implement HL7 standard in our APIs.