Working in an environment where you have many communities collaborating on a project, it is sometimes difficult to ensure that there's overall coordination among all of the moving parts. A particular example that comes to mind in regard to FHIR was the degree of variation among the
various workflow resources:
In DSTU 2 we had these key ones (I include Procedure because it is a record of what had been done which shares many of the characteristics as the record of what was asked to be done).
Some of my findings:
The code associated with workflow could be named type or code or item.code
Date of the order had different names event-date (with a specific code identifying which date was the order placement date), data, or orderedOn.
The references to the placer of the request and fulfiller of the request were identified in different ways.
These are the who, what, and when of the workflow for things which FHIR acknowledged were somewhat arbitrary distinctions (the difference between a referral and a procedure and a diagnostic test) worked differently depending on which one you needed to use, EVEN though, you could never actually be sure which was the correct one.
STU3 addressed most of these issues, and the FHIR STANDARD (because that's going to happen soon) will do even more. The good news is that the right governance was in place to address this issue as we tested this out, and corrections were applied.
As for me, I'm seriously considering how to adopt some search aliases for current STU2 based APIs to ensure that the APIs will do what people meant them to.
Keith
various workflow resources:
In DSTU 2 we had these key ones (I include Procedure because it is a record of what had been done which shares many of the characteristics as the record of what was asked to be done).
- DiagnosticOrder
- ProcedureRequest
- Procedure
- ReferralRequest
Some of my findings:
The code associated with workflow could be named type or code or item.code
Date of the order had different names event-date (with a specific code identifying which date was the order placement date), data, or orderedOn.
The references to the placer of the request and fulfiller of the request were identified in different ways.
These are the who, what, and when of the workflow for things which FHIR acknowledged were somewhat arbitrary distinctions (the difference between a referral and a procedure and a diagnostic test) worked differently depending on which one you needed to use, EVEN though, you could never actually be sure which was the correct one.
STU3 addressed most of these issues, and the FHIR STANDARD (because that's going to happen soon) will do even more. The good news is that the right governance was in place to address this issue as we tested this out, and corrections were applied.
As for me, I'm seriously considering how to adopt some search aliases for current STU2 based APIs to ensure that the APIs will do what people meant them to.
Keith
