50 min | Review BSeR issues and status | John Loonsk | - FHIR Messaging and RESTFul submit
- Both eCR and BSeR- Depending on the discussion, we expect that each will have a fully specified FHIR messaging and RESTFUL submit approach
- FHIR Message bundle and guidance for transaction bundle for REST to encapsulate
- What is the difference between a RESTFul post of a message and a bundle (or a different grouping)? Not so much trying to describe a different grouping, just trying to provide guidance. Trying to tease out whether or not all the original resources conveyed via a RESTFul Submit/post.
- We are specifying 2 approaches- FHIR message and a RESTFul submit- Some think that the FHIR Message is a RESTFul submit, but it doesn’t have a FHIR message header or top level type of message. We have gotten push back from DiVinici regarding implementing the FHIR message header when it isn't perceived as not needed.
- Found during a connectathon-
- When a bundle is posted, the receiving server doesn’t do anything with it.
- The RESTFul approach didn’t necessarily have a bundle at the top level, but could.
- FHIR Message header focus is Task
- Could use Task for Both BSeR and eCR
- FHIR Message header is for sender and ultimate receiver through “hops”
- FHIR Message header “Reason”
- If you have an intermediary, its desirable to have that information at the top level so the intermediary doesn’t have to unpack the entire thing just to facilitate transport. This is only possible with the message header.
- Task resource for workflow inside
- Task intent
- Facilitator of transport, regardless of content.
- Status
- Once accepted it becomes in progress
- Business Status
- What is the difference between Task Status, vs Task Business Status? – Using business status allows you to explicitly show the state from the business point of view as opposed from the infrastructure point of view. From the task state machine you could not tell what the source of the status change is.
- Thought we had found the appropriate values in Task Status, but would like to further discuss the use of Business status.
- There is no 'withdrawn' in task state machine, and it doesn’t convey who did the act.
- Needs more analysis and research. Interested in harmonizing with 360x.
Status of eCR- still in recon for a few comments, would like to align the CDA eICR and the FHIR eCR which will help with completing the transforms. |
| 40 min | BSeR FHIR IG ballot recon | AbdulMalik Shakir | See ballot comment spreadsheet - 33 affirmative votes, 31 needed to pass. Did receive 18 negatives. 154 comments. Some were submitted to gForge but all were put into the spreadsheet for reconciliation.
- Can use the STU update process to continue to refine the IG.
- Very subjective- need clarification
- Depends on adoption and the significance of change
- Whether or not it goes to ballot, is dependent on the workgroup
- A comment was made stating that the IG should go to FHIR V4. Can we change to V4 before publishing and does this require another ballot? Needs to be approved by the workgroup, Graham (FHIR). Would need to be approved by TSC.
- A project must be registered so the update work can take place.
Motion: John moves to approve moving the BSeR FHIR IG to v4 subsequent to ballot comments #12, 77, 106, 109, 112, 115. Second: Sarah DISCUSSION: There is no change at all, they actually added an extension to accommodate the needs in V3 that didn’t exist (practitioner role extension), but would be taken out in v4 because it does. Also aligns this with US Core. eCR will be brought up in WQ1 Vote: 7,0,1
- In looking at the negative comments, it seems like there is a sense that this might need re-ballot.
- Comments grouped into classes and then subclasses
- Clarity
- Completeness
- Consistency
- Correctness
- Credibility
- Once categorized, then grouped
- 13 typos
- 12 where there are broken links or blank pages
- 13 360x and US Corse alignment
- 16 R4 and workflow upgrades
- 16 terminology
- 84 not categorized
- Typos- 1, 2, 20, 22, 24, 28, 33, 34, 70, 88, 121
- Motion- AMS moves to approve these comments as dispositioned (persuasive).
- Second- Sarah G.
- Vote- 8,0,1
- Blank pages- 3,4,5,6,92,95,96,98
- Not simply blank pages, but content weren’t provided and will need to be added. Will need to be distributed and reviewed prior to publishing
- Motion- AMS moves to approve these comments as dispositioned (persuasive).
- Second- Sarah G.
- The disposition should be clear about not just corrected prior to publication will also be made available for review prior to publication. “This omission will be corrected and made available for review prior to publication.”
- Will discuss problems with creating the IG and the IG publication tool TQ3.
- Vote- 8,0,1
- Broken or missing Links- 23, 51, 59, 101
- Either there should be a link and its missing, or the link doesn’t take you were it was intended.
- Disposition updated to: All links used throughout the specification will be validated, confirmed, and made available for review prior to publication.
- Motion- AMS moves to approve these comments as dispositioned (persuasive).
- Second- John Loonsk
- Vote- 8,0,1
- Bundles vs Lists- there is a solution better than Lists (Vassil)- 11
- Rather than having a service request with supporting information as bundles, have different service requests. The supporting info should be sliced and specialized for each observation. Have 6 profiles of service request, with a set of specific service request constraints. This would eliminate bundles, and replaces them with specializations of service requests.
- This restricts so local needs not included in the guide will be supported.
- How would this look to an EHR implementer? Would be easier to consume.
- Do we restrict to just the identified use cases or allow for extensibility? Will discuss extensibility.
- Will look at slicing of supporting information and will come back to the group for reconciliation.
|
