Ping @thomas.beale any news on this from e.g. Graphite?
After a demo of openFHIR today I would very much like to have something like the “Registry” (extended from Demographics) in openEHR so that we could properly model and long-time store stuff that is often exchanged using FHIR.
An example is stuff in and related to GenomicStudy - FHIR v6.0.0-ballot2 that we want to use and store for Precision Medicine, over time surviving major FHIR version updates and be able to serve both using V4 (using a hack) and V6.
Of course some more general graph querying language than AQL would also be needed for Registry - best would be if it could cross-query the EHRs and Registry in the same optimized queries. See hints about AGQL in e.g. EHRs with different system_id in the same server? - #37 by erik.sundvall
1 Like
I will have something to share imminently. It covers:
- physical entities
- kinds - e.g. a type of device such as Philips model 700 obstetric ultrasound machine
- individuals, e.g. a particular Philips model 700 obstetric ultrasound machine with UDI 1234, currently in maternity department at clinic ABC, with maintenance history etc
- resources - uses of things and people
- social entities - the usual Party and related entities, plus relationships
- assets - ownership / renting etc of things by Parties
- registry - as per openEHR
The model has a much more fully worked out form of the physical entity category above, plus a lot of improvements over the draft form currently at openEHR.
One of the main improvements is the ability to have a ‘smart ref’ to any kind of Entity,
- a) between entities (e.g. parthood)
- b) between data and entities, e.g. a ref from a heart rate recording to the device (any of: category of device, exact device kind (model of machine), or an actual individual device).
More soon.
This may be well off-topic, apologies if so, but we have been working on a Public health use-case, where the top-level object is a ‘Case’ and not necessarily a person i.e. an EHR object.
However in all other respects, so far with the use of Folder and links, the underlying public health documentation documentation works really well with the Folder/Composition/Entry structures.
We expect to propose a new top-level object which is pretty well identical to an EHR but does not imply a person.
And some documentation e.g Vaccination history is associated with an actual EHR but linked to a Case.
We think it is important to clearly distinguish this from an actual person, but we suspect that there could be wider uses than just Public health Case, so we would probably suggest making it a bit more abstract.
I raise it here in case some of this overlaps with Registry ideas but what we are talking here is not reference/registry as such.
1 Like
@ian.mcnicoll I think most (or all?) of what you are describing could be covered by a combination of (a possibly imprived version of) the registry/entity/demographics based approach discussed in this thread combined with som top level “SYSTEM” root object above both the EHR and demographics/registry. (This is something e.g. @sebastian.iancu has pointed out a long time.)
I agree that there are many use cases where one would like to use the openEHR approach (archetypes/templates etc) for things that ar not neccesaruily rooted in an individual’s EHR. For example cases or samples used in laboratory settings and research. When we build genomic related flows we can use openEHR for referral and response when e.g. bacteria samples come from patients in a suspected food poisioning investigation, but would need to build something totally different, non openEHR-based, for the samples that come from a food samples suspected to be the source. (Same thing with infection control where we want to sequence bacteria/virus swabs from door handles hospital rooms. Such samples are related to patients but not neccesarily 1:1 to a specific patient. It would be nice to be able to treat those things in ways and systems similar to samples from patients and also make cross-cutting queries.
Due to archetyping we wouldn’t need a huge number of new classes to cover a huge number of use cases…
< forward-looking-statement >
…but I do believe we would in the long run benefit from adopting (not reinventing) a more general graph query language. Of course function calls in AQL could cover many recurring “registry/demographic” query use cases and be a bridge to the AQL-world. AQL would likely remain used in many systems for looong time. Implementation-wise under the hood I would expect that some implementors would just use the graph querying language for everything and have a query translator to be able to handle AQL (forever) for suitable use cases.
< /forward-looking-statement >
we can use openEHR for referral and response when e.g. bacteria samples come from patients in a suspected food poisoning investigation, but would need to build something totally different, non openEHR-based, for the samples that come from a food samples suspected to be the source.
That is exactly one of the use cases in scope for us and we are fairly confident that much of the ‘working documentation’ can be handled within the existing EHR RM, as long as we have a new top-level container which is clearly represents a ‘case’ or other non-patient collection of compositions.
Most likely a good idea. Can we assume that the kind of ‘case’ you are thinking of here corresponds to an ‘outbreak’ (or suspected outbreak)? For such things the information added (initially at least) will be reports of certain kinds of infection. possibly connected to identified individuals, possibly just aggregated reports from a clinic (i.e. numbers of individuals with xyz symptom).
One interesting question is what constitutes a new case? Are 2 x MRSA +ve at the same clinic one case or two? Are all new Covid cases in a particular town one case or more?
In my understanding, the general idea is usually to make a case = some independent event, e.g. a patient zero creating infection in some geography, or @erik.sundvall 's example of (say) Listeria emanating from some product delivered by a certain local processing location / factory.
Another thing to consider is what kind of assessments (Evaluation) and Orders (Instruction) are likely? Likely to include PH reporting actions, among others. It will be interesting to see if there are any new needs in RM OBSERVATION, INSTRUCTION, ACTION.
We’ve been using GraphQL at Graphite. It definitely has limitations. For one thing, you can’t write a GraphQL query that has a WHERE clause equivalent containing anything other than the AND logical operator. To express a WHERE clause with ORed conditions, you need separate copies of the query, each with one of the conditions modelled in it.
This is exactly the space we are in, and not just infectious disease, other public health situations like environmental incidents, radiation scares, legionalla detected in air-con unit etc. So there may be no human individuals at all, or indeed there may be multiple individual persons associated with a case which then may transform into a cluster or outbreak.
So far, as long as we can introduce that top-level idea of a ‘case’ rather than an EHR, the standard RM classes have worked fine, though. Definitely some new archetypes or modifications of the work done by @KBarwise and @heather.leslie.
That seems to be a slightly grey area, as of course it may not be immediately apparent that 2 human cases are associated. Discussed this week but we anticipate multiple ‘human cases’ to need to be handled under a single public health case, and will probably use folders to associate the various lab reports, interviews etc associated with the human case.
1 Like
@thomas.beale, has Graphite investigetad if GQL (or Neo4J’s related Cypher) has the same limitations? It seems to be partly another kind of tool/language. See GQL links in e.g. EHRs with different system_id in the same server? - #37 by erik.sundvall
(Adding syntactic sugar shortcuts to GQL like AQL did to Xpaths would create what I tentatively would call AGQL 
- see Update March 31 below)
[Update March 20: I found these two sources informative and full of context regarding GQL, Cypher and the standardisation process
GQL: The ISO standard for graphs has arrived | AWS Database Blog
…and…
Introduction to Graph Query Languages. From SPARQL to Gremlin.]
[Update March 31: Adding text for context from a previous not openly available post:
GQL (Graph Query Language - Wikipedia) seems to finally have been made a standard now. If it is/becomes well supported by graph databases, then I was thinkning that perhaps some Archetype-based syntactic sugar on top of GQL (could be called AGQL) and simple preporocessing/translation of the query might do the trick without us having to reeinvent any new wheel or stretch AQL’s tree-focused view too far. With syntactic sugar I mean simplifications like AQL paths have done to xPath in the form of .../attributename[at0123]/...]
Sorry for going off topic.
2 Likes