|HL7 ITS Meeting Minutes||Date: 2020-05-05|
|Facilitator: Paul Knapp||Note taker(s): Brian Pech|
|x||Paul Knapp||PK||Knapp Consulting|
|David Booth||DB||Hawaii Group|
|Bryn Rhodes||BR||Database Consulting|
|Quorum Requirements Met: yes (chair + 2)|
- Andy is no longer working in the healthcare space and not running for his existing co-chair position.
- Jeff Brown will be standing for Andy's position.
- PK updates on RDF sub-group efforts; they are making progress on JSON-LD.
- Ask RDF to roll up prior minutes, give HL7 a copy for storage on Confluence.
- Future RDF minutes should be copied to Confluence/ITS
- Changes for Turtle RDF FhIR specification need to have JIRA tickets approved by ITS, not simply the RDF sub-group.
- Do we want to change our call time? Day?
- First Wed. of the month at 3PM EDT seems to work, so we will move calls to then.
- Do we need a joint call with FHIR-I in the next couple weeks for converged topics? No issues are apparent. Jeff will check with FhIR-I and get back to us.
- Paul in a VA group looking at problems that FHIR might be encountering. There is a document Lloyd put together about recommended exchange mechanisms; InM is looking at it but ITS likely needs to look as well.
- It is not clear whether the recommendations cover every conceivable use cases - that is, the context within an organization, or across org. boundaries matter.
- Guidance is good, prescriptive universal pronouncements probably not.
- Not enough attention to downstream consequences of decisions made in creating implementation guides that cover complex information exchange - more than one resource, an information set.
- Send the entire set of resources, so the entire set of resources is sent.
- a granular exchange, only send the lead resource which opens the path of the other resources. But this does not work in a guaranteed way because of timing issues - for a given encounter, you will get the resources on the FhIR server now rather than those at the time of encounter creation. This is result of how FhIR servers function in a default manner.
- Consider that delivering the whole bolus of information - the deliverer will know which time related resources are relevant for that graph of resources.
- the granular delivery does not do this, it pulls the current version of the resources in the graph. To solve this, the resources could be versioned.
- A client could get a time dimensioned version of a resource graph for a patient but how does the client know the sequence of queries needed to elaborate the relevant information for a disease episode for a specific patient?
- Is this a problem? yes.
- Next call June 3 at 3 PM EDT