Tools in development
What we are building next. Each list below is the first version we intend to ship. Tell us what is missing, or ask to hear when one is ready.
Interoperability
In developmentStage: Defining scopeFHIR Front for HL7 v2 Systems
Many systems that hold the data a FHIR app needs only send HL7 v2. This tool reads the feeds they already produce, keeps a FHIR copy of what they say, and answers FHIR requests from it, so the source system does not change.
First version
- Receive ADT, ORU and SIU feeds over MLLP, and acknowledge each message.
- Map them to FHIR R4 Patient, Encounter, ServiceRequest, Observation, DiagnosticReport and Appointment, starting from the HL7 v2-to-FHIR Implementation Guide.
- Serve those resources through a read-only FHIR API, with search on the common parameters.
- Produce resources that validate against US Core.
- Carry identifiers properly: each MRN keeps its assigning authority, and a patient merge (A40) becomes a link between records.
- Record where every resource came from, pointing back to the message that produced it.
- A mapping workbench: paste a v2 message and see the FHIR it becomes, with the rule behind each element.
After that
- Writing back: a FHIR order becomes an HL7 v2 order message, and the acknowledgement becomes the response.
- SMART on FHIR authorization.
- Notifications to subscribers when a new message changes a resource.
- Local codes mapped to LOINC and SNOMED CT on the way in.
- CA Core+ profiles for Canadian deployments.
What we want to know
Which system would you put it in front of, and which FHIR resources would you need first?
Interface analysis
In developmentStage: PrototypeInterface Feed Profiler
Every interface project starts by finding out what a feed really contains, which is rarely what its specification says. This tool reads a sample of messages and writes that report for you.
First version
- Load a sample of HL7 v2 messages, or FHIR resources, from files.
- A population report: how often each field is filled, by message type and trigger event.
- Value distributions, and the code systems found in each coded field.
- Z-segments and unexpected segments, listed with examples.
- Identifier authorities seen in patient identifier fields.
- A comparison against a conformance profile you choose.
- A report you can export as HTML or CSV. The sample never leaves your machine.
After that
- Two samples compared, such as before and after an upgrade.
- A draft interface specification generated from what the feed contains.
- De-identified example messages for each pattern found, safe to share with a vendor.
What we want to know
What do you check by hand today when a new feed arrives?
Terminology
In developmentStage: DesignCode Crosswalk Assistant
Mapping local lab, imaging and medication codes to standard terminologies is slow, and most of the time goes on finding candidates rather than deciding. This tool suggests the candidates. A person still makes every decision.
First version
- Import local code lists from CSV: lab tests, imaging procedures, medications.
- Ranked candidate matches in LOINC, RadLex and RxNorm, from text matching and language-model similarity.
- Accept, reject or override every match, with a note. Nothing is mapped without a person.
- SNOMED CT matching against your own licensed copy.
- Export as a FHIR ConceptMap or CSV.
- A history for each mapping: who decided, when, and why.
After that
- Re-checking existing maps when a terminology releases a new version.
- Shared review, with a second person confirming each decision.
- Loading the finished map into a terminology server.
What we want to know
Which code sets would you map first, and how many local codes are in each?
Suggest a feature, or ask to hear when it is ready
The lists above are drafts. If something you need is missing, or one of them is the wrong first step, say so.
