I often get into discussions of Functional and Structural roles in terms of security, because that is where roles most often get discussed. In this space,
In the case of a taxi driver delivering a baby, their structural role is taxi driver, that is how they are licensed. But their functional role might be "attending OB", in terms of what role they are taking on. In the context of
Structural roles describe static capabilities, functional roles dynamic behaviors.
I came upon the realization today that these concepts can also be applied to "Resources" in FHIR. Here's the context: How should one represent a transcription on a diagnostic test or procedure reported as a text report via an HL7 ORU message?
Is this DocumentReference, because basically the content is a document? Or should it be represented as a DiagnosticReport because the content is a report on a diagnostic test?
The DocumentReference resource has to do with what it is, it's physical structure and components. The DiagnosticReport focuses more on the functionality it provides, and the purposes and ways it would be expected to behave (e.g., the state diagram that might be associated with it). See 4+1 Architectural View Model for yet another way to look at these distinctions.
My answer in this case, to this either/or question, is essential my father's default answer to any either/or question. Yes.
The report COULD be accessed via DocumentReference, and in this case, the API capabilities would be focused on the "document-ness" of the content. It COULD also be accessed via DiagnosticReport, and the API capabilities would be focused on the "diagnostic-ness" of the content.
In the Venn diagram describing these thing, some documents are diagnostic reports (and others are different kinds of things, e.g., scans of identity cards), and some diagnostic reports are documents (and others are simply combinations of structured data that eventually can be rendered in document form, but don't exist natively in that form).
And FHIR is simply the interface that is provided to access all these things, and when a thing has dual nature, well, why not make it accessible either way.
- Structural role depends on is who you are, or what specific skills or licensing you have attained
- Functional role depends on how you behave, what you are doing.
In the case of a taxi driver delivering a baby, their structural role is taxi driver, that is how they are licensed. But their functional role might be "attending OB", in terms of what role they are taking on. In the context of
Structural roles describe static capabilities, functional roles dynamic behaviors.
I came upon the realization today that these concepts can also be applied to "Resources" in FHIR. Here's the context: How should one represent a transcription on a diagnostic test or procedure reported as a text report via an HL7 ORU message?
Is this DocumentReference, because basically the content is a document? Or should it be represented as a DiagnosticReport because the content is a report on a diagnostic test?
The DocumentReference resource has to do with what it is, it's physical structure and components. The DiagnosticReport focuses more on the functionality it provides, and the purposes and ways it would be expected to behave (e.g., the state diagram that might be associated with it). See 4+1 Architectural View Model for yet another way to look at these distinctions.
My answer in this case, to this either/or question, is essential my father's default answer to any either/or question. Yes.
The report COULD be accessed via DocumentReference, and in this case, the API capabilities would be focused on the "document-ness" of the content. It COULD also be accessed via DiagnosticReport, and the API capabilities would be focused on the "diagnostic-ness" of the content.
In the Venn diagram describing these thing, some documents are diagnostic reports (and others are different kinds of things, e.g., scans of identity cards), and some diagnostic reports are documents (and others are simply combinations of structured data that eventually can be rendered in document form, but don't exist natively in that form).
And FHIR is simply the interface that is provided to access all these things, and when a thing has dual nature, well, why not make it accessible either way.
0 comments:
Post a Comment